Skip to content

Agents & AI

What is an agent?

An agent is a program that uses an LLM to decide what to do next. Instead of following a fixed sequence of steps, it works in turns: the model reads the goal and the context so far, then proposes the next action. That action might be a tool call, a question for a person, or a final answer. The result of each action becomes context for the next turn, and the loop continues until the goal is met.

The Conductor agent turn loop An LLM proposes the next action. Conductor validates the proposal, persists state, and schedules the work. Workers, MCP tools, remote agents, and people execute it. Results are saved and start the next turn. LLM decides the next step proposes a tool call, a question, or an answer Conductor validates the proposal · applies approvals persists state · schedules the work Workers your code MCP tools tools + data Remote agents A2A protocol People review + input results are saved and start the next turn

In Conductor, that loop runs as a durable workflow. The model's proposal is data, not a command. Conductor validates it, applies any required approvals, and only then schedules the work. The work itself runs as ordinary tasks, using the same building blocks a workflow already has: your workers, MCP tools, remote agents, and people. Because every result is persisted before the next turn starts, a crash, deploy, or long wait never loses the agent's progress.

Three ways to build

The paths are complementary. A production workflow can use native AI tasks, invoke a compiled Conductor Agent, and delegate specialist work to a remote A2A agent in the same durable graph.

Operating principles

Adaptive behavior stays manageable when the execution contract is explicit. These principles apply across all three authoring paths.

01 Model output is a proposal Plans and tool arguments must pass schema validation, policy, guardrails, and approval before they become executable work.
02 State belongs in the workflow Progress, waits, decisions, and results live in durable execution state—not only in the memory of an agent process.
03 Side effects cross task boundaries Workers and system tasks perform approved actions through bounded, observable interfaces with defined retries and timeouts.
04 Every turn is governable Proposals, policy outcomes, approvals, inputs, outputs, retries, timing, and terminal state remain inspectable and recoverable.

What you gain

Conductor applies the same durable execution model to adaptive agents and ordinary distributed workflows.

Durable executionResume from persisted progress across crashes, deploys, retries, and long waits.
Policy and guardrailsValidate model proposals and constrain tools, inputs, fan-out, time, and cost before execution.
Turn-by-turn observabilityInspect the durable record of decisions, policy outcomes, task data, timing, and failures.
Human controlPause without losing state, collect review or input, then resume the same execution.
Framework and protocol interoperabilityUse supported framework bridges, MCP tools, and remote A2A agents behind stable workflow boundaries.
Ordinary workflow compositionPlace agents beside APIs, workers, branching, schedules, notifications, and compensation logic.

Where to start

Choose the boundary that matches what you are building, then deepen only the part of the platform you need.

Build Choose an authoring path Compare the three agent models, then learn the native model and retrieval tasks available to declarative workflows. Agent conceptsLLM orchestration
Integrate Bring agents into a durable graph Compile SDK or framework-authored agents locally, or invoke independently deployed agents through A2A. Conductor AgentsA2A integration
Operate Design for production Apply the reference architecture, then move through governance, evaluation, deployment, recovery, and operations. Production architectureProduction path