Most Agents in production today are slow, unreliable, expensive, inefficient, and routinely overexpose sensitive data to AI models. The problem is not the models themselves—it is that Engineers have applied a non-deterministic orchestration pattern to workflows that should be run deterministically. We've been missing a practical way to combine the dynamic intelligence of AI, the orchestrating language of code, and the operational guarantees of traditional software.

The industry is shifting its focus toward Coding Agents, which are far more capable, adaptable, and efficient because these Agents can write and execute code in real-time to achieve goals. And yet, the application of Coding Agents is almost exclusively directly by Engineers, never by the Agents we put in front of customers or use to run the business.

Why is that?

We don't have a code problem. We have a trust problem. The output from coding models is fundamentally risky and unreliable, so it is relegated to the developer's machine or sandbox.

The industry needs an architecture that allows Agents to create deterministic plans freely, while giving operators confidence that execution remains governed, observable, durable, and recoverable.

This is the Agentic Unlock. Let's go.

The Orchestration Problem

Orchestration services operate by continuously converting Events into Commands. Each Event is recorded and incorporated into the service’s Context. With Context, the orchestrator determines what should happen next and emits the appropriate Command. The orchestrator itself does not perform the work—it maintains state, makes transition decisions, and delegates execution to other components responsible for producing side effects.

Contrast this pattern with Choreography, where events are published to a central pub/sub hub and consumers decide for themselves what to do next. In Orchestration, the orchestrator controls the flow explicitly, determining what happens next and how to recover when things go wrong. It coordinates the work, but does not perform it.

AI Agents are nothing new from this perspective—they are a class of Orchestration service. Agents event-source their context and pass it to an AI model to create the next message-shaped Command for the harness to interpret and execute on, providing the response back to the model as an Event which updates Context which is passed to the Model to produce the next Command, and so on. Events in, Commands out.

Orchestration is really powerful: the Agent has complete flow control, it can use the power of AI reasoning to decide what should happen next, for example it can determine if and when it has met its goal and stop. It can use its context to "learn" over time how to achieve its goals better.

The challenge in reality is that achieving a goal is a workflow that combines deterministic and non-deterministic components. The problem with using an AI model for both is that it does not scale like normal compute. The Engineer must address at least:

1. Context usage and size limits (also has data privacy implications)
2. Turn count limits
3. Inconsistent tool sequencing
4. Limited number of addressable tools

---

Prior Art at Apple, Anthropic, Cloudflare, and Docker

Industry leaders have reached the same conclusion about the limits of Agentic Orchestration via tool calling and have published about the substantial benefits of leveraging coding models instead. Apple's CodeAct (July 2024) demonstrated that models perform better when they generate executable plans rather than repeatedly selecting tools one step at a time. Anthropic's MCP code execution architecture (Nov 2025) and Cloudflare's Code Mode (Sept 2025) both arrived at the same operational insight: the LLM should not sit in the middle of every workflow transition. Instead, the model should synthesize a program, workflow, or execution plan and allow a runtime to carry out the mechanics. The payoff is dramatic: lower context usage, fewer tool-calling failures, reduced latency, and the ability to scale beyond a handful of tools or steps.

Apple reported up to a 20% increase in task success rates and roughly 30% fewer action steps when models generated executable code instead of performing stepwise tool orchestration. Anthropic demonstrated reductions approaching 98.7% in orchestration-related context usage by moving execution logic out of the prompt loop and into generated code running against MCP servers. Cloudflare showed that exposing thousands of APIs as explicit tools fundamentally does not scale: over 2,500 API endpoints could be compressed into roughly 1,000 tokens of context (where an equivalent MCP server without Code Mode would consume 1.17 million tokens) by replacing endpoint-level tool definitions with generalized code execution primitives.

The solution is clear: use code instead. And yet, this approach is rarely available to Agents in production. The problem is trust. How do we apply necessary security controls around untrusted code?

Anthropic's MCP implementation exposes tools as filesystem-backed APIs and has the model generate TypeScript that executes inside a sandboxed Node.js runtime using the MCP TypeScript SDK. Cloudflare's Code Mode converts tools into typed TypeScript APIs, gives the model a single "write code" capability, and executes the generated JavaScript inside isolated Workers sandboxes using V8 isolates. Docker takes a complementary angle with the MCP Catalog and Toolkit (Nov 2025) and the MCP Gateway, brokering discovery and execution of MCP servers as isolated containers. In every case, the operational model depends on allowing the Agent to generate or invoke arbitrary code.

This introduces a new class of problems:

• sandboxing
• capability isolation
• runtime governance
• observability
• policy enforcement
• auditability

The generated programs themselves become opaque operational artifacts that are difficult to inspect, validate, constrain, or adapt. In practice, this limits adoption outside of software engineering workflows where arbitrary code execution is already operationally tolerated.

The industry is converging on the correct direction: the model should author the plan as code, not orchestrate every transition. But there is still a disconnect between non-deterministic planning and deterministic execution. We need a planning representation that preserves the expressiveness of AI-generated orchestration code while remaining observable, governable, durable, and operationally safe.

---

---

"I've never met a Finite State Machine I did not like."
—Bruce O'Dell, Senior Principal Security Architect @ Best Buy, 2020

Execution We Can Trust: State Machines

State Machines and by extension State Charts give technical and non-technical users common language to express any process over any time scale as a finite set of states and events that transition between them. State machines inherit the language of the domain to express virtually any process at any scale—from a single http request to the role of a CTO.

The structure of a state machine is declarative. This means one can document rather than code a system where all of the following are explicitly defined in advance. This document is a Charter, and it includes:

• states
• transitions
• activities
• data flow

A basic pure state machine Charter may look like this:

{
  "states": {
    "A": {
      "on": { "GOTO_B_EVENT": "B" }
    },
    "B": {
      "on": { "GOTO_A_EVENT": "A" }
    }
  }
}

As we move beyond the theoretical model and add side-effects, the machine includes a reference to a side-effect producing command. The implementation of that activity is defined elsewhere in a registry, creating a hard separation between planning and execution.

{
  "states": {
    "A": {
      // Side-effect: runtime invokes the registered activity.
      "activity": "doAActivity",
      "on": { "GOTO_B_EVENT": "B" }
    },
    "B": {
      "activity": "doBActivity",
      "on": { "GOTO_A_EVENT": "A" }
    }
  }
}

There is still a need for execution semantics in the declarative model for real-world use, especially for transition conditions and data transforms. Introducing expressions for pure logic and transformation (math, ternary, map, filter, reduce, etc.) gives the LLM enough imperative power to compose the machine without giving it dangerous authority over I/O.

A pure expression language like JSONata—the same language AWS Step Functions uses for state input/output transforms—fits this role exactly. The machine can declare how data flows between states without ever describing how data is fetched or written:

{
  "states": {
    "A": {
      "activity": "doAActivity",

      // Pure JSONata, evaluated when the state is entered.
      // Each binding becomes a new context variable that later
      // states, guards, and activities can read.
      "assign": {
        "fullName":   "firstName & ' ' & lastName",
        "domain":     "$substringAfter(email, '@')",
        "isInternal": "domain = 'bluefolders.ai'"
      },

      "on": {
        // Guards: first matching `cond` wins; the final entry
        // with no cond acts as the default branch.
        "GOTO_B_EVENT": [
          { "target": "B", "cond": "isInternal" },
          { "target": "A" }
        ]
      }
    },
    "B": {
      "activity": "doBActivity",
      "on": { "GOTO_A_EVENT": "A" }
    }
  }
}

The data flow is explicit: doAActivity returns a user record into context, the assign block derives fullName, domain, and isInternal from it, and the GOTO_B_EVENT transition uses isInternal as a guard to choose between B and a self-loop on A.

Every expression is pure: it reads from context, returns a value, and produces no side effects. The machine cannot fetch data, mutate a database, or call an arbitrary API—it can only describe how known values combine to produce new values and decide which transition to take next.

Coding models are phenomenally good at building state machines. Distributed systems, workflow engines, protocols, databases, UI frameworks, and operating systems all rely on some form of state transition model to coordinate complex behavior over time. Model training has more than 70 years worth of examples to draw upon.

---

Agentic Chartering

To achieve a goal, the Agent authors a pre-planned sequence of steps as a Charter; a dispatcher interprets this structured plan as deterministic orchestration; the Agent receives the final result.

A Registry is used to expose capabilities to the Chartering Agent. The capabilities can be classified according to their risk-level and be used to apply appropriate policies like required approval gates. The identity of the Agent can be leveraged to perform Role-based Access Control. The Registry may also expose a search function to support progressive discovery at scale, so the Agent only is passed the relevant capabilities.

Charters are treated as untrusted input and executed under a Zero Trust security model. The LLM does not receive direct authority over infrastructure, credentials, filesystems, networks, databases, or arbitrary runtime execution. The model can propose a machine, but the runtime decides whether that machine is admissible. The Charter may reference capabilities, but it cannot create capabilities. It may bind data, but it cannot fetch data. It may describe transitions, but it cannot bypass policy. Every side effect crosses a registered activity boundary.

The primary advantage of this architecture is that the agent can perform deterministic orchestration without a code sandbox as a security boundary because the model lacks fundamental access beyond the basic primitives defined in the pre-approved Registry. The runtime exposes only governed activities with known side-effect boundaries and every side effect occurs through existing infrastructure that is already observable, auditable, and policy-controlled.

Charter Governance

The Charter is a static declarative description of a State Machine, but that does not mean execution is operationally safe. The model may still generate an invalid, dangerous, or inefficient process.

Fortunately, Charters are inspectable and testable artifacts, so many of the familiar software engineering patterns apply including static analysis and automated testing. Because the execution graph is declarative, we can apply decades of existing workflow and compiler theory directly to AI-generated plans, including:

• validating referenced activities
• verifying schemas
• checking transitions
• enforcing policy constraints
• identifying dead states
• ensuring retry correctness
• evaluating compensation coverage

We can also execute Charters against mock registries and synthetic data before execution. Any errors found in analysis are passed directly back to the authoring coding model as feedback to support improving the output. The model iterates until it produces a Charter that satisfies governance constraints, which may take several turns.

Charter Approval

The Charter is data, so it can be readily transferred and transformed. If static analysis reveals sensitive activities, the entire Charter can be routed for approval by the user or operator.

Charters can be easily visualized, which assists humans to quickly understand their operational implications.

Further, the Charter can be extended to include additional orchestration steps prior to execution, for example for human in the loop approval, with deterministic confidence it will occur and that no other aspects of the machine's function have regressed.

Charter Execution

At execution time, the Charter becomes a durable execution graph.

The runtime progresses state, schedules activities, records history, applies retries, waits for external events, enforces policy, and resumes after failure. Activities are where side effects happen. The Charter describes how the traffic cop will work, i.e. when those activities are allowed to run.

State machines are simple, but durable, distributed execution requires infrastructure to host the machine including processing messages, storing event history, and performing recovery. Then there are retries, timeouts, backoffs, priorities and a whole lot more.

Thankfully this undifferentiated overhead is completely solved on a platform like Temporal.

Temporal is particularly well aligned with this model because these are already its native primitives. Workflows are state machines. Activities are side-effect boundaries. Signals, queries, and updates model external events. Retries, replay, history, and long-running execution are part of the platform rather than responsibilities the Agent has to invent. This allows the coding model to focus exclusively on expressing the intent, without having to worry about the implementation details of these real world operational complexities.

Chartering does not require Temporal. However, Temporal provides the ideal primitives a Chartering Agent can compose natively: Workflows and Activities.

Durability and Recovery

State Machines may be guaranteed, but activities can still fail—the Charter defines what happens next.

A downstream API may reject a request, a timeout may occur, a workflow may wait forever, an API may become unavailable. These are typical operational conditions in distributed systems.

Because execution semantics are explicit, recovery behavior must be part of the plan itself:

• retries
• backoff strategies
• timeout handling
• escalation
• compensation
• rollback
• dead-letter routing
• human intervention

Compensating Transactions naturally emerge through the Saga Pattern. If a sequence of side effects partially completes, the Charter can define compensating activities that return the system to a valid business state.

Thankfully, this entire category of operational complexity is already solved infrastructure.

Temporal in particular is built around durable workflow execution under failure. Workflow state is event-sourced and replayable. Activities are isolated side-effect boundaries with built-in retries, timeout handling, heartbeating, cancellation, and compensation semantics. Signals allow workflows to react to external events asynchronously. Long-running processes can survive process crashes, deploys, outages, and machine restarts without losing execution state.

This is exactly why Chartering maps so naturally onto Temporal: the model authors the machine, but the platform owns execution durability and recovery.

Charter Promotion

After execution, successful Charters can be optionally saved in the Registry and provided to the coding model upon future calls. An Agent may:

1. Use the promoted Charter as-is
2. Extend the promoted Charter with additional steps
3. Write a new Charter using the promoted Charter as a positive example

Promoting Charters to the Registry enables the agent to continuously improve based on what is needed and what works.

Changing the World

Consider the primitives provided to the coding model via the registry as it is composing the Charter. Those primitives can reference anything with inputs and outputs—a function call, a Workflow, a state machine, and also other Agents.

In other words, you can have an Orchestrator tool call a Charterer, and you can Charter an Orchestrator, both in the context of a broader goal. These patterns stand independent and complementary to one another and can be composed to achieve bigger and broader goals than either can accomplish alone.

Goals are Workflows that produce Outcomes in a Domain. Every application, task, role, or job fits this description, regardless of where that Workflow falls on the human-to-agentic spectrum.

With Agentic Chartering, AI has the foundational leverage necessary to reliably execute on Workflows of its own making. These Workflows could last seconds or run continuously and never stop. They will find application across every Domain there is.

There will be a Cambrian explosion. This will change the world.

---

Summary

Agentic Chartering separates non-deterministic planning from deterministic execution.

The registry defines trusted capabilities. The coding model authors a constrained declarative control plane—a Charter. The runtime validates, executes, secures, observes, and recovers the resulting workflow as a durable state machine.

This gives Agents the freedom to orchestrate complex systems dynamically while remaining bounded by explicit execution semantics, governed side-effect boundaries, and Zero Trust infrastructure controls.

Agentic Chartering enables AI-authored orchestration with workflow-engine-level trust: no general-purpose sandbox required.

What's Next

• Demo Video, Case Study - Migrating Dispatch Assistant from Orchestration to Chartering @ Navion Logistics
• Open Source Repo — Helpful primitives and example application