Julep provides Agent task orchestration, tool invocation and status management capabilities to help teams implement multi-step AI automation processes into production environments.

julep

Julep’s core parameters and statistics

Julep is a production-oriented Python native Agent orchestration framework. It is officially positioned as "durable, composable AI agents" - upgrading Agents from temporary scripts to production-level data flows that are crash-recoverable, accurately retryable, and traceable at every step. It is not another LLM chat package, but a complete engineering system from process definition to production deployment.

Projects	Public Information
Official positioning	Durable, composable AI agents — flows that crash and resume, retry safely, and explain every step
Delivery form	Python SDK (native) + CLI + API (v3 is rewritten to be mainly Python native)
Open source license	Apache-2.0 (GitHub public repository)
Latest version	3.0.0rc3 (2026-07-14, confirmed by pyproject.toml)
Community size	About 6,600 stars, 971 forks, 20 watchers
Main languages	Python 97.6%, HCL 1.1%, Shell 0.7%
Supported platforms	Python 3.8+, Node.js 16+ (SDK), API
Persistence engine	Temporal (optional), DBOS/Postgres (optional)
Official documentation	docs.julep.ai

Evolution of product form: Julep has undergone a complete reconstruction from the v1 API platform to the v3 Python native framework. v1 is an Agent platform in the form of managed control plane + API, while v3 completely shifts to the "define-by-construction" Python @flow model - developers use standard Python code to define the process, and the framework automatically compiles it into an immutable IR (intermediate representation), and then obtains persistent execution capabilities through the optional backend (Temporal/DBOS). This means that v3 is no longer a "platform", but a library + CLI that can be embedded in any Python project.

A brief comment: Julep does not make the model smarter, but makes the Agent process as debuggable, recoverable, and auditable as production-grade software.

Publicity verification: Julep's official emphasis on "flows that crash and resume, retry safely, and explain every step" is not a marketing rhetoric - its core architecture is indeed designed around "restorability". The IR compiled by @flow contains a complete step dependency graph, and can be used with Temporal/DBOS to achieve accurate replay of any node. This is a real pain point for production-level Agent scenarios, but is overkill for one-off script scenarios.

Julep’s users and market recognition

Julep is currently in the stage of "technical community recognition first, commercial verification later". Market signals mainly come from the activity of the open source community and the pace of project iteration. Enterprise-level customer and revenue data have not yet been made public.

Community Popularity: Approximately 6,600 stars and 971 forks on GitHub. For a Python framework focusing on production-level agent orchestration, it has moderate to high attention. 20 watchers and 3 open issues indicate that the project maintainers maintain a fast response and cleanup rhythm. There are 5 main contributors, of which creatorrr is the main creator of the project, and claude and codex are AI auxiliary contributors - this is not uncommon in AI-native projects, but it also means that the core team is smaller.

Target customer group: From the perspective of project documentation and CLI design, Julep's main audience is the Python engineering team that "needs to put Agent into production" - they have clear requirements for process governance and execution reliability, rather than just proof of concept. v3 abandons the managed API form and turns to Python native + CLI, indicating that the team is more inclined to serve the developer group that can manage the infrastructure independently.

Industry Benchmarking: Julep intersects with LangChain/LangGraph, CrewAI, and Temporal itself in the "Agent Orchestration" ecosystem but does not completely overlap. LangChain focuses more on LLM call abstraction and chain combination, CrewAI focuses on multi-Agent role-playing collaboration, and Temporal provides a general persistence execution engine but lacks the Agent semantic layer. Julep's unique position lies in directly binding "Agent semantics (@flow, Reasoner, tool)" and "persistent execution (Temporal/DBOS)" within the same programming model.

Julep’s cost advantage: open source self-hosting reduces the entry barrier for Agent production

Julep's cost model is fundamentally different from that of SaaS Agent platforms - it does not charge based on API calls or the number of Agents, but is delivered with an open source license, and the cost structure shifts from "subscription fee" to "infrastructure + operation and maintenance investment".

C client/individual developer: completely free. pip install --pre julep will allow you to use the complete @flow definition CLI tool and dry_run debugging mode locally. Individual developers can complete process development and local testing without an API Key, and additional infrastructure is only required when persistent execution (Temporal/DBOS) or production deployment is required. For learning and prototyping scenarios, the cost is almost zero. Developer/Team: The framework itself is free (Apache-2.0), but the main costs after production come from three aspects: 1) Operation and maintenance costs of Temporal or DBOS clusters - Temporal Cloud is billed based on workflow execution, and self-hosting requires server and operation and maintenance manpower; 2) LLM API calling fees - Julep itself is not bound to a model provider, and developers need to bear the APIs of Anthropic, OpenAI or other models. Cost; 3) Infrastructure deployment - if you use the Helm/KEDA publishing link of julep apply, you need to maintain the Kubernetes cluster and S3 storage.

Enterprise/Private: The open source license (Apache-2.0) allows any commercial use and modification, and there is no purchase threshold at the license level. However, the real costs of enterprise-level implementation include: the establishment of Temporal clusters, the authentication and permission management of operation and maintenance MCP tools, and the continuous maintenance of process version changes. Compared with commercial Agent platforms (such as Relevance AI, CrewAI Enterprise), Julep's explicit subscription cost is zero, but the implicit operation and maintenance cost requires the team to have sufficient infrastructure capabilities.	Cost dimension	Julep (open source and self-hosted)	Commercial Agent platform (such as Relevance AI)	Self-built orchestration
License/subscription fee	Zero (Apache-2.0)	Billed by seat/execution volume	Development labor cost
Infrastructure	Self-managed Temporal/DBOS + K8s	Platform hosting	Full stack self-built
LLM calling fee	Based on actual usage (custom-selected model)	Usually bundled or increased price	Based on actual usage
Process governance	@flow + CLI built-in	Platform provides visualization	Self-research required
Persistence/recovery	Built-in Temporal/DBOS layer	Platform transparent processing	Self-research required

Julep’s core features

Julep's capabilities revolve around the five stages of "Definition → Compilation → Debugging → Deployment → Operation and Maintenance". It is not an isolated list of functions, but a complete link from process definition to production observability.

• @flow declarative process definition: Define the entire Agent process with the @flow decorator above the Python function. @flow compiles primitives such as tool(), think(), cond(), switch(), each(), reschedule() in the function body into immutable IR at definition time (not runtime). This means that the process topology is determined before deployment, and there is no uncertainty caused by "model free play" at runtime. The | operator is used to merge records, and h["key"] is used to extract fields. These compile-time operations do not consume LLM tokens.

• Reasoner declarative reasoning node: Reasoner is a declarative object that encapsulates the LLM call intent, including name, model (such as anthropic:claude-haiku-4-5-20251001), system prompt and reply output type (TypedDict). Reasoner does not make LLM calls directly - it just describes "what it wants the model to do" and the actual call is triggered inside @flow by think(reasoner, prompt). This separation allows Reasoner to be replaced by the fake function in dry_run mode, enabling completely offline process testing.

• Tool registration and permission control: Register the tool through @tool(effect="read", idempotent=True) and explicitly declare the effect type (read/write) and idempotence. When deploying, pass deploy(triage, tools=[lookup_ticket], reasoners=[support_reply]) to freeze the calling surface of tools and Reasoner - any unregistered tool model cannot be called. This is stricter than LangChain's tool list delivery method and is more suitable for production auditing.

• Pure pure functions and sandbox execution: @pure("ticket_prompt") The decorated function is deterministic pure conversion logic (input → output, no side effects) and can be safely executed by Julep's WASM sandbox (julep[wasm] extra). This provides an engineering foundation for extracting sensitive logic from the IR and running it in an isolated context.

• CLI full life cycle management: julep CLI provides a complete tool chain from discovery to deployment - ls lists all Agents, show views details, graph outputs cross-Agent DAG, run local execution, lint static verification, test runs pytest, trace renders execution traces, doctor bounded pre-check, deploy freezes + releases. The design of the CLI draws on dbt's "module-oriented developer experience" - it treats all @flows in a directory as an addressable graph, and precisely controls the scope of operations through selector syntax (tag:support, state:modified, +agent).

• Application production deployment primitive: For formal production context, Julep provides Application object - aggregating PipelineSpec (including flow, reasoners, capabilities, lane, eval_packages, snapshot) into a releasable unit. julep plan detects drift, julep apply performs immutable release (S3-CAS + Helm reconciliation), and julep status aggregates running status. The release process uses Ed25519 signatures to ensure artifact integrity.

Hidden linkage (expert view): The real design ingenuity of Julep lies in the combination of "topology determined at compile time + recovery at runtime". In traditional Agent frameworks, the LLM decides what tool to call next at runtime, which brings unpredictability and debugging difficulties. Julep's @flow locks the step topology during the definition period, and LLM only participates in reasoning within the Reasoner node (not process decision-making), which makes the process behavior predictable, testable, and replayable. At the same time, through the persistence of Temporal/DBOS, the status of executed steps can be accurately restored after execution interruption - this combination of "deterministic topology + persistent status" is a differentiated technical route in the field of Agent orchestration.

Julep’s model and version evolution

Julep's version line has undergone a complete rewrite from v1 (managed API platform) to v3 (Python native framework), v2 does not exist or is not publicly released.

It is recommended to adopt the internal governance method of "process version number + node change record":

1. Process version (business logic change).
2. Node strategy version (model, hints, tool changes).
3. Run the parameter version (timeout, retry, approval threshold).

This can prevent platform updates from making the process untraceable.

Julep’s technical advantages

The technical value of Julep does not lie in "stronger models", but in upgrading the Agent process from "uncontrollable script concatenation" to "compilable, recoverable and auditable engineering products".

Define-by-construction compilation paradigm: The core innovation of @flow is "compile at definition time and execute at runtime". think(), tool(), cond(), etc. written by developers are not immediately executed function calls, but declarative operations that append step nodes to the IR. This means that the topology of the process is completely determined before deployment, without the uncertainty of runtime LLM's free choice of tool or path. This "compile-time topology determination" route belongs to the "engineering safety" end of the Agent framework - compared to LangChain's dynamic routing, it sacrifices some flexibility, but in exchange for predictability and auditability.

Two-tier persistence architecture: Julep's persistence layer is pluggable - Temporal (via julep[temporal] extra) provides an enterprise-class workflow engine, and DBOS (via julep[dbos] extra) provides lightweight persistence based on Postgres. Both share the same set of IR semantics: the process can be resumed from the last persistence step after interruption, the results of LLM calls are recorded, and the side effects of tool execution can be played back. This is a qualitative improvement in reliability compared to the simple memory execution + logging solution.

Immutable publishing and signing mechanism: The julep apply publishing process uses S3 as the content-addressed storage (CAS). Each publishing package contains immutable IR and dependency snapshots, ensuring integrity through Ed25519 signatures. The CA_BUNDLE_ALLOWED_SIGNERS mechanism allows the runtime to only accept releases signed by specified public keys. This is very important in multi-team collaboration or CI/CD pipelines - to prevent unauthorized process changes from being pushed to production.

Explicit declaration of the Tool call surface: deploy(..., tools=[...], reasoners=[...]) explicitly declares the set of tools and Reasoners that the process can call - any tool that is not in this list cannot be called by the model. This is different from the "pass the tool list to LLM, and LLM decides whether to call" model of most Agent frameworks, and is closer to the security model of "API permission declaration". With the semantic annotation of @tool(effect="read", idempotent=True), the data flow and side effect scope of the process can be statically analyzed before deployment.

Why it’s more stable: Failures of traditional Agent frameworks are usually manifested as "irreproducibility" - LLM selects different tool paths in different calls, resulting in different results for the same input. Through compilation-time topology locking + persistence step recording, Julep transforms "irreproducible Agent failure" into "locatable specific node failure", changing troubleshooting from "retrying the entire process" to "retrying the failed node".

How to use Julep

The entry path to Julep starts with a local Python environment and gradually expands to persistent execution and production deployment.

Get started quickly in 3 minutes - local installation and debugging:

pip install --pre julep

Julep 3 is currently an RC version and requires the --pre flag. Once installed, full @flow definitions and dry_run debugging mode are available locally, no API key required.

from typing import TypedDict
from julep import Reasoner, deploy, flow, pure, think, tool

class SupportReply(TypedDict):
    reply: str

@tool(effect="read", idempotent=True)
def lookup_ticket(ticket: str) -> dict[str, str]:
    return {"ticket": ticket, "queue": "billing",
            "summary": "Use the duplicate-charge runbook."}

@pure("ticket_prompt")
def ticket_prompt(hit: dict[str, str]) -> dict[str, str]:
    return {"queue": hit["queue"], "context": hit["summary"]}

support_reply = Reasoner(
    name="support_reply",
    model="anthropic:claude-haiku-4-5-20251001",
    system="Draft one concise support reply as JSON.",
    reply=SupportReply,
)

@flow
def triage(ticket: str) -> dict[str, str]:
    hit = lookup_ticket(ticket, retries=2, timeout_s=5)
    prompt = ticket_prompt(hit)
    answer = think(support_reply, prompt, timeout_s=10)
    return hit | answer

deployment = deploy(triage, tools=[lookup_ticket],
                    reasoners=[support_reply])
result = deployment.dry_run(
    "Customer was charged twice.",
    reasoners={"support_reply": lambda v: {"reply":
                f"{v['queue']}: {v['context']}"}},
)
print(result.value)

Architecture link diagram:

  LLM API (Anthropic/OpenAI)
         ↑
   [ Reasoner ] ← Declarative reasoning node, does not participate in process decision-making
         ↑
  [ @flow IR ] ← Step topology determined at compile time (immutable)
         ↑
  [ Temporal / DBOS ] ← Optional persistence layer to provide crash recovery
         ↑
  [ Tool / MCP / Pure ] ← Registerable external capabilities

Control flow: Developer writes @flow → compile to IR when defined → deploy() freeze tool/Reasoner surface → dry_run() or julep run local debugging → julep deploy production release (persistence + signing).

Usage scenarios for several entrances:

Entrance	Suitable Stage	Key Actions
Python SDK (@flow)	Process definition and local debugging	pip install --pre julep, write @flow, use dry_run to verify
julep CLI	Multi-process management and deployment	julep ls/graph/run/lint/test/trace/deploy
Temporal integration	Production persistence execution	pip install julep[temporal], configure Temporal endpoint
Application object	Production-level multi-process release	Define PipelineSpec, julep plan/apply/status

Typical implementation rhythm: First use Python SDK + dry_run to verify the process logic and tool call accuracy on a small sample; then connect to Temporal (or DBOS) for persistence execution verification to confirm that recovery and retry behaviors are as expected; finally push to the staging/production environment through the deploy/plan/apply pipeline of the CLI. It is recommended to add julep lint and julep test steps in CI/CD to detect process definition issues before merging.

Engineering Pitfall Guide

1. Infinite loops and Token inflation control: In @flow, if the output of Reasoner is continuously fed back to a tool or cond node, an infinite loop may form. The triple constraints of retries (number of single-step retries), timeout_s (single-step timeout) and max_steps (the upper limit of the total number of steps in the process) must be used to prevent idle token burning. When deploying, workflow timeout settings at the Temporal layer are the last line of defense.

2. IR compile-time error troubleshooting: @flow generates IR at definition time rather than runtime, which means that some logical errors (such as type mismatch, tool not registered) will be exposed when import. When debugging, it is recommended to use julep lint <agent> to do static checking instead of waiting until an error is reported at runtime. The immutability of IR also means that the process topology cannot be hot modified once deployed - the complete plan → apply release link must be followed.

3. Security and unauthorized governance: tools=[...] declared in deploy() is a "whitelist" of tools that can be called by the model. But still be careful: the implementation of the tool function itself may perform dangerous operations (delete, write, pay). It is recommended to add secondary confirmation or dry-run mode to the implementation layer of tools with effect="write". For production environments, the Temporal activity level can configure retry strategies and exception handling, but the best practice for irreversible operations is to add confirmation points yourself in the tool implementation.

4. MCP Snapshot and Credential Management: Julep's McpSnapshot mechanism allows capturing the schema of MCP tools at deployment time, but credentials for MCP connections (such as JWT) should not be stored outside of worker_secret_environment - these values ​​only exist when the Worker is running and should not be touched by the control plane. When designing the tool's authentication model, you need to separate credential injection and schema discovery to avoid hardcoding keys in the snapshot_source callback.

Julep’s Product Pricing

Julep's pricing model is "open source core + infrastructure pay-as-you-go" without the subscription tiers of traditional SaaS.

The framework itself: Apache-2.0 license, completely free. There are no function restrictions, no restrictions on the number of Agents, and no restrictions on the number of calls. All core capabilities (@flow, Reasoner, CLI, IR compilation dry_run, deploy) are available in the open source version.

Persistence execution layer: When using Temporal self-hosting or Temporal Cloud, you are billed according to Temporal's own pricing model (Temporal Cloud charges based on the number and duration of workflow executions, while self-hosting only requires infrastructure fees). When using DBOS, based on cost of Postgres instance (cloud database or on-premises). Julep itself charges no additional fees for this tier.

LLM API Fee: Paid directly by the developer to the model provider (Anthropic, OpenAI, Google, etc.). Julep does not proxy API calls and does not add a markup to model fees. Supported models are specified by the provider prefix in the model parameter (e.g. anthropic:claude-haiku-4-5-20251001).

Production Deployment Infrastructure: julep apply publish link relies on S3 (or compatible object storage) and Kubernetes cluster. This part of the cost depends on the team's existing infrastructure - teams that already have K8s clusters have almost no new costs, while teams that need to build new ones need to assess cluster fees.

Cost items	Julep framework	Third-party dependencies	Description
License	Zero (Apache-2.0)	—	Can be used commercially and can be modified
Agent execution	Zero	Temporal/DBOS	Pay-as-you-go Temporal or self-hosted
LLM calls	Zero	Anthropic/OpenAI, etc.	Pay-as-you-go model provider
Infrastructure	Zero	K8s + S3	According to actual resource consumption

Julep application scenarios

Julep's applicable scenarios focus on Agent tasks that "require persistence guarantees and multi-step collaboration" rather than a single question and answer.

Dimensionality reduction strike scene:

• Customer service upgrade and work order processing link: triage → information retrieval → attribution analysis → receipt generation → upgrade judgment. Each step may involve calling different tools (checking knowledge base, checking orders, writing receipts), and the status needs to be kept consistent over a long period of time. Julep's persistence capabilities ensure that even if the LLM call times out or the tool returns an exception, the process can resume from the last successful step.

• Content review and publishing pipeline: content retrieval → AI preliminary screening → manual review → classification annotation → multi-platform publishing. Each node involves different tools and Reasoners, and spans multiple systems (CMS, social media API, moderation system). Julep's compile-time topology determinism and node-level retry prevent this multi-system serial process from rolling back as a whole due to an occasional failure.

• Sales Lead Processing and Scoring: Multi-channel lead access → Information completion → Enterprise information retrieval → Intention scoring → Follow-up suggestions → CRM writing. It involves three types of nodes: data query (external API), reasoning (Reasoner scoring), and writing (CRM operation). Julep's effect annotation can clearly separate read-only and write operations for easy auditing.

General adaptation scenarios:

• Operational processes that require API scheduling across multiple internal systems and require execution reliability.
• Approval chains that require human participation - Julep's reschedule() primitive supports processes waiting for external confirmation at specific nodes.

Not suitable for scenarios:

• Single question and answer or simple information retrieval - it is cheaper to use the LLM API directly, and Julep's orchestration capabilities are just overweight infrastructure in this scenario.
• Fully automated, irreversible operations without human intervention (such as payment execution, contract signing) - the error rate of Agent is still not suitable for complete separation from manual review.
• Exploratory tasks that require dynamically determined toolchains at runtime - Julep's compile-time topology locking limits this flexibility.

Applicable people for Julep

• Python backend/platform engineering team: has clear requirements for process reliability and observability, and is willing to invest in infrastructure (Temporal/DBOS) in exchange for production-level guarantees for the Agent process. Julep's @flow mode is close to the standard Python development experience, and the learning curve is mainly about understanding the semantics of compile-time/run-time separation.

• AI Application Architect: Need to design multi-step, cross-system Agent workflow, focusing on auditing, playback and fault recovery capabilities. Julep’s immutable publishing and signing mechanism enables AI processes to be incorporated into standard CI/CD and change management processes.

• DevOps/SRE team: AI processes need to be incorporated into the existing operation and maintenance system (observable, alarms, rollbacks). Julep's julep plan/apply/status pipeline design philosophy is consistent with Infrastructure as Code (IaC) tools - plan detects drift, apply performs immutable releases, and status aggregates running status.

Dissuade the crowd:

• Only a one-time LLM call or a simple chained prompt-Script mode is required, without the overhead of an orchestration framework.
• Business teams without Python engineering background - Julep's pure code definition approach is not friendly to non-developers.
• Teams that need a visual process drag-and-drop interface - Julep does not provide a GUI orchestration tool, and the process definition is entirely in the form of code.

Summary and Outlook

The core value of Julep is to upgrade Agent from "uncontrollable LLM call series" to "compilable, recoverable, and auditable engineering systems". It is not intended to lower the threshold for Agent development - on the contrary, it will increase the cognitive load of developers in the early stage (understanding @flow compile-time semantics, configuring Temporal clusters, designing release pipelines), in exchange for lower troubleshooting costs and higher process certainty in production environments.

Current limitations: 1) v3 is still in the RC stage, and the API may continue to change before the official version; 2) The community is still small (6.6k stars), and ecological plug-ins and third-party integrations are limited; 3) CLI and Helm deployment links require the team to have K8s operation and maintenance capabilities; 4) Lack of official visual monitoring panel, observable reliance on Temporal Web UI or self-built OpenTelemetry Link; 5) The official pricing page and commercial support terms have not been made public, and commercial terms need to be confirmed through GitHub or Discord communication before enterprise purchase.

Follow-up observations: Release cadence and API stability commitments for 3.0.0 production; more persistence backend support beyond Temporal/DBOS; how quickly the community-driven MCP tool set is growing; and whether a hosted control plane option will be available again (v3 is currently a fully self-hosted route).

Procurement/Adoption Risk Assessment: For teams with existing Temporal or K8s infrastructure, Julep adoption risk is low - you can start with a small-scale pilot to first verify the stability of @flow on existing infrastructure. For teams that need to build infrastructure from scratch, it is recommended to first evaluate whether the operation and maintenance costs of Temporal or DBOS are within an acceptable range, and also pay attention to the API freezing time of the v3 official version. Both types of teams should complete persistence recovery and failure drills in the staging environment before entering production traffic.

Related tools: CrewAI, langchain

Version Info

• Julep 3.0.0 RC3 ：Julep 3 is the third release candidate and continues to improve the production deployment link and Temporal integration. Please refer to the official release log for details. （2026-07-14）
• Julep 3.0.0 RC2 ：There is no official precise date yet, RC2 focuses on application deployment and primitive stability enhancement. （~2026-07）
• Julep 3.0.0 RC1 ：There is no official precise date yet. The first candidate version of Julep 3 has completed the renaming of composable_agents to julep and the freezing of the core API. （~2026-06）
• Julep v1 (API Platform Edition) ：Julep v1 is the Agent API platform, providing managed control plane and API form interaction. v3 is a complete rewrite and there is no migration path. The v1 code is retained in the v1 branch, and documentation is available at v1.docs.julep.ai. （~2025）