The layer where an agent becomes a designed system.
Prompt, retrieval, tools, logic and code on one canvas — with state, memory and human approval points treated as first-class design elements rather than configuration. This is the capability that determines whether your agents are reproducible enough to be changed by someone other than the person who wrote them.
One canvas
Eight node types across three categories, executed in the direction of the connections
Structured prompts
Thirteen attribute fields, reusable templates, and reasoning traces you can read
State and memory
Industry term bases, disambiguation, session isolation, long-term memory mounting
Multi-agent
Supervisor dispatch, query rewriting, intent strategy, cluster autonomy, shared tools
Design the flow as a diagram, not as a description in a ticket.
Nodes fall into three categories — trigger conditions, logic nodes and end modules — and execution follows the direction of the connections. The practical value is not the drag-and-drop. It is that the flow becomes something a reviewer can argue with, which a written specification cannot.
| Node type | Category | Use it for |
|---|---|---|
| Start | Trigger | Entry point and the variables, channel and user context the run begins with. |
| LLM | Logic | Model selection, temperature, maximum tokens and system prompt, set per node rather than per agent. |
| Knowledge retrieval | Logic | Query against a mounted knowledge base, with citation display configurable per node. |
| Plugin / tool | Logic | Call any mounted skill or plugin. Mounting happens at build time from the panel, and enablement is managed centrally. |
| Message | Logic | Compose the reply to the user, or push to a channel. |
| Condition / branch | Logic | Routing. This is where most production behaviour actually lives. |
| Code block | Logic | Python or JavaScript for transformation logic the other nodes cannot express. The escape hatch that keeps you off a platform limitation. |
| End | End module | Termination, result assembly and the payload handed back to the caller or API. |
Parallel branches and loop sub-flows
Fan work out across nodes and join it back, or wrap a set of nodes in a loop with a termination condition. Sub-flow templates can be saved and reused, which is how a twenty-node process becomes three maintainable components.
Failure behaviour you configure, not discover
Automatic retry on exception, and timeout degradation to a fallback path. Both are designed on the canvas before go-live rather than inferred at 3am during your busiest week.
Human breakpoints inside the flow
Insert an approval step before a consequential action, with a condition that decides whether it triggers and an approver who receives it. The condition can be a business rule — a transaction above a threshold, for example.
Hot reload
Changing the flow definition does not require restarting the service. For estates with many agents this is the difference between a two-minute fix and a maintenance window.
Visual monitoring
Live execution state and flow analysis data, so you can see which node is slow or failing rather than reading it out of a log.
Design from the description
A natural-language description of the business process generates a draft workflow with knowledge bindings, tool permissions, prompts and evaluation rules attached. It is a starting point that saves an afternoon of assembly — and it still gets reviewed line by line.
The three-stage method we require. Define the flow, stating the input, output and logic of every step. Design the error handling, where it is needed. Then test — single nodes first, whole flow second. Skipping straight to whole-flow testing is how a twenty-node process spends three weeks failing for one reason that a node-level test would have found in an hour.
Orchestration in numbers
Because a prompt is a specification, not a wish
Rather than inventing your own topology
Confidence, disagreement, and boundary
It is drawn as a diagram, and the diagram is the spec
How much orchestration your workflow actually needs
Most first projects need the bottom-left or bottom-right. Starting top-left because it is interesting is the most reliable way to miss a deadline.
Human-in-the-loop multi-agent
Complex work where a person must stay close. Worth the orchestration cost — this is where the value usually is.
Autonomous with sampled review
Complex but well-supervised by sampling. Needs strong evaluation, because you will not see every decision.
Single agent, full review
Simple work, every decision reviewed. The safest starting point and often sufficient for the whole first year.
Do not build this yet
Simple and nobody is reviewing. That combination is how incidents happen.
Thirteen fields, because a prompt is a specification.
Free-text prompts are not reviewable, diffable or auditable. Structured prompts put the specification into fields, which means a change is a change to one attribute rather than a rewrite that quietly alters three other behaviours.
Role
Who the agent is. The strongest single field, because it constrains everything else.
Profile
Including language and description — the background that a role alone does not convey.
Skills
What it is capable of. Kept consistent with the tools actually mounted.
Goals
What it is trying to achieve, stated so success is checkable.
Rules
The operational rules. Where most behaviour is actually specified.
Constraints
Hard limits. What it must never do, however the request is framed.
Tone
Register and voice. Contested by every stakeholder, so it belongs in a field.
Attention
What to notice. Used heavily for compliance and safety-relevant agents.
Definition
The terms that matter for this business. Ties into the industry term base.
Example
Worked examples. Often the highest-return field per character written.
Output Format
The shape of the answer. If it feeds another system, this is the contract.
Workflow
The procedure it should follow, in order.
Initialization
Opening behaviour and framing on first contact.
Plus the model settings
Model, temperature, maximum tokens and system prompt, set per node on the canvas.
Templates, optimisation and traces
A separate prompt template module holds reusable definitions, imported directly into a prompt configuration. Four structured templates ship as defaults: a general structure, a task-execution template that organises work into steps, a skill-invocation template for calling plugins and workflows, and a knowledge-base answering template that includes fields for questions the agent must not answer and words and phrases it must not use.
That last template is worth pausing on. In regulated deployments the prohibition list is more valuable than the capability list, and having it as a first-class field makes it reviewable by the person who is accountable rather than buried in prose.
Automatic prompt optimisation rewrites a prompt with a model. We treat its output as a draft for review, and so does the vendor — the tooling states plainly that it is a reference requiring modification against real business practice. In governance-sensitive contexts we recommend against running it unattended at all, and sometimes recommend not having it enabled during evaluation runs, because a prompt that changes between runs makes two results incomparable.
Reading the reasoning, not guessing at it
Chain-of-Thought tracing in the observation module lets you see the decomposition the agent actually performed rather than the answer it gave you. Two practical uses: finding a more efficient instruction that produces the same result, and producing precise feedback for model tuning.
CoT, and the two thinking modes. Chain-of-Thought prompting handles complex decomposition and reasoning. At the node level you choose between ReAct, where the model calls tools and knowledge freely, and Plan-and-Execute, where it emits a plan first and works through it — with an iteration parameter bounding the maximum rounds. For a configuration-sensitive scenario, a scenario-specific analysis framework can be written into the guidance chain so the supervisor dispatches along your method rather than an improvised one.
Thirteen fields, because a prompt is a specification
We insist on all thirteen before an agent is built. Field 2 — the explicit non-goals — is the one that prevents most of the incidents we are asked to clean up.
| # | Field | What it settles | If you skip it |
|---|---|---|---|
| 1 | Purpose statement | What the agent is for, in one sentence a regulator could read | Scope creep nobody notices until audit |
| 2 | Explicit non-goals | What it will not do — the most important field on this page | The agent does things you never approved |
| 3 | Input contract | The exact shape and source of every input | Silent failures on malformed data |
| 4 | Output contract | The exact shape of every output, including the refusal case | Downstream systems break unpredictably |
| 5 | Knowledge sources | Which governed sources, at which granularity | Confident answers from ungoverned documents |
| 6 | Tools and permissions | What it may call, with what authority | A capability escalation nobody approved |
| 7 | Escalation triggers | Confidence threshold, disagreement, boundary breach | The agent guesses instead of asking |
| 8 | Human approval point | Exactly where a person must sign off | You find out about the decision after it lands |
| 9 | Failure behaviour | What it does when it cannot complete | A confident wrong answer instead of an honest failure |
| 10 | Evaluation set reference | Which test set this version must pass | No way to tell if a change made it worse |
| 11 | Version and owner | Who owns it and which version is live | Nobody knows what is actually running |
| 12 | Cost and latency budget | What this task is allowed to cost | A quiet budget line that surprises finance |
| 13 | Logging requirements | What gets recorded, and for how long | No evidence trail when you need one |
The part nobody specifies, and the part users notice first.
Users do not experience your prompt or your retrieval strategy. They experience whether the agent remembered what they said three questions ago, and whether it understands what your business calls things.
Multi-layer information processing
Three layers run before the model sees the question: enterprise terminology and FAQ recall, coreference resolution — working out what "it", "the second one" and "that department" refer to — and multi-turn dialogue processing. Coreference is where conversational agents most visibly fail, and most teams have never realised it was a separate capability.
Industry term base
A maintainable term base that teaches the model your internal vocabulary. Enterprises run on abbreviations, legacy product names and internal coinages that appear nowhere in any training corpus. Without this, every such term becomes a hallucination opportunity, and with it, accuracy improves measurably on exactly the questions that matter.
Unified memory, cross-agent distribution
Conversations across downstream agents are managed centrally, which is what allows memory to be distributed between agents. A customer who has already explained their situation does not explain it again to the billing agent. This is a genuine architectural decision with a genuine trade-off, and it needs a deliberate policy about what is shared.
Three memory modes
Full retains everything in context, which maximises coherence and hits context limits fastest. Window keeps the most recent N turns, which is cheap and forgets the beginning of a long conversation. Summary has the model condense history, which preserves arc at the cost of detail. Mode is a per-agent decision driven by task length, not a default.
Session isolation and identity binding
Sessions are isolated by identifier and bound to the enterprise account system, so memory does not leak between users or between a departing employee and their successor. Long-term memory can be mounted as a component within a workflow, which lets you decide per agent whether continuity is appropriate.
Tool mounting discipline
An agent can mount multiple plugins, and the set is managed centrally so enablement is auditable. Deep-research agents extend their capability through Skills rather than through an unbounded tool list — the more durable design, because a Skill is a procedure someone wrote and reviewed, and a tool is a capability someone enabled.
A decision we make with you, explicitly. Full memory feels better in a demo and behaves worse in production: it is the most expensive mode, it is the one most likely to surface an earlier statement the user has since changed their mind about, and it makes the hardest conversations to audit. Window memory forgets the opening constraint. Summary memory loses the exception. We pick the mode per agent and write the reason into the configuration.
How work arrives, and where a person must take it back
The same seven stages every time. The value of a drawn-out flow is that everyone can see where the human is — and that is exactly what an auditor asks for first.
Intake
Work arrives from a person, a schedule, an event, or another agent — with the context it needs attached.
Parse and validate
Check the input against the contract. Malformed input fails here, loudly, rather than half way through.
Plan
Decide the path. Either a designed sequence or a reasoned plan with a step budget.
Execute with tools
Call the systems of record. Every call logged with arguments and result.
Self-check
Does the output satisfy the output contract? If not, retry within budget or escalate.
Approval or commit
Where a human must sign off, they do — with the reasoning and the sources in front of them.
Record and learn
The decision, the evidence and the outcome go into the log. Failures become new test cases.
Most multi-agent designs fail at dispatch, not at the agents.
A specialist agent is not difficult. Deciding which specialist should handle a request, giving it the right context, and knowing what to do when it fails — that is where multi-agent systems actually break. Nine mechanisms address it, and each of them is a design decision you should make deliberately.
| Mechanism | What it does | Why you need it |
|---|---|---|
| Supervisor architecture | A supervisor agent recognises a complex request spanning several intents, decomposes it, produces an execution plan and dispatches to specialist agents. | The default shape. Without it, routing decisions end up scattered across every agent. |
| Constrained chain-of-thought dispatch | A scenario-specific analysis framework is configured as the reasoning chain, so the supervisor plans along your method. | Turns dispatch from an improvisation into a documented decision process. |
| Query rewriting | The incoming question is rewritten using conversation memory, knowledge base content and industry terminology before intent matching. | "Do the same for the other one" routes correctly, or does not route at all. |
| Hybrid intent matching | Code rules and natural-language inference are combined. A specific channel can have code rules forcing every query to a designated intent. | Handles both the high-volume known cases and the long tail, with a hard override where needed. |
| Intent strategy operations | Intent descriptions and the dispatch reasoning chain are maintained per business scenario and tuned over time. | Recognition quality is an operations discipline, not a configuration task you finish once. |
| Cluster autonomous scheduling | The supervisor decomposes a goal, executes subtasks in parallel, and consolidates and verifies the result. | Turns a linear flow into genuinely parallel work on long tasks. |
| Fault self-healing and checkpoint resume | A failing agent instance is replaced automatically and the task resumes from its last checkpoint. | Long tasks must survive one component failing. Design the idempotency key yourself — this is not built in. |
| Cross-agent tool marketplace | Internal plugins are published centrally and reused across business agents. | Stops four agents having four slightly different implementations of the same finance or ticketing call. |
| Shared workspace collaboration | Real employees, digital employees and background agents work in the same space, sharing document, ticket and database views, with multi-person annotation, task assignment and agent-to-agent relay. | Human, human and AI in one surface — the collaboration pattern, not just the tooling. |
A2A, for estates that already have agents. Agent-to-Agent protocol support lets agents built on other platforms — including a competitor's — be registered, scheduled and governed alongside yours. For any organisation with existing AI investment, this is the difference between a phased programme and a rebuild. We would rather propose that than a rip-and-replace, and it is usually the better commercial outcome as well.
Where work leaves the agent and returns to a person
Escalation is not failure. An agent that escalates correctly is trustworthy; one that never escalates is not. Track the rate — a rate that falls to zero is a warning, not an achievement.
Four proven patterns. Start from one of them.
Most enterprise workflows are one of these four with your own field names on them. Designing from a pattern gets you to a working draft in an afternoon; designing from a blank canvas gets you to the same place in a week.
Parallel or serial tools, then model synthesis
Call several tools — parallel where they are independent, serial where one feeds the next — then have a model node assemble the result. The most common pattern by a wide margin, and the right default.
Plan–Reflect
A planning node proposes an approach, a reflection node critiques it, and the loop continues before output. Chosen when quality matters more than latency: translation, code, and copy where a first attempt that reads well is not the same as one that reads correctly.
Long-form generation
Several model nodes each responsible for one section, with a final consolidation. Keeps each generation inside a manageable scope and makes a weak section fixable without regenerating the whole document.
Deliberate slow-thinking
Think, refine and consider constraints before answering. Chosen for quantitative and mathematical accuracy, where the extra reasoning round is cheaper than an incorrect figure that reaches a decision.
Choosing between fast and deliberate
This is the same dual-path idea as elsewhere in the platform, applied at workflow level. Built-in, well-understood intents should take the fast path and cost almost nothing. Genuinely complex intents should get the reasoning path even though they are slower — because a fast wrong answer on a regulatory query is more expensive than a slow right one, and a fast right answer on a trivial query costs you user goodwill.
Workflows can also be published as an MCP server, which means a flow you built becomes a callable capability for other agents. Combined with publishing as an agent or a REST endpoint, one piece of process design can be consumed by a chatbot, an internal system, or another agent's tool list.
Modularity as a discipline
Splitting an agent into modules and reusing them across scenarios is the difference between an estate you can change and an estate you can only rebuild. Practically it means: common sub-flows extracted rather than copied, prompts in the template module rather than inlined, and tools published centrally rather than mounted individually in forty agents.
Each of these is a small discipline to adopt at the start and an expensive retrofit to attempt later.
Four proven patterns. Start from one of them.
Most multi-agent designs fail at dispatch, not at the agents. Start from a pattern that is already known to work for your shape of problem.
Planner and specialists
One planner decomposes the task and dispatches to specialists, then synthesises. Use when the work splits along genuine expertise boundaries — and only then. Splitting by department chart instead of by work is the classic failure.
Sequential pipeline
A designed sequence with explicit branching. Use when the process is documented and stable. The least glamorous option and usually the right one for a first workflow.
ReAct loop
Think, act, observe, repeat until done or bounded. Use when the path cannot be written down but the goal is clear. Requires a step budget or it will run until you stop it.
Parallel fan-out with adjudication
Several agents attempt the same judgement independently and a third adjudicates. Expensive and slow, but genuinely useful where the decision is high-stakes and rare.
How work arrives, and where a person must take it back.
The second half of this page is the part enterprises most often leave implicit, and then discover in production: if nobody decides where a human takes over, the system will decide by accident.
| Trigger | Mechanism | Notes that matter in production |
|---|---|---|
| Scheduled | Time trigger, configurable by day and time. | The workhorse behind recurring reports, scheduled notifications and periodic checks. Idempotency matters more here than anywhere else — a retried run must not double-post. |
| Event | Event trigger fires when something happens. | Cleanest for "state changed, do something". Pair it with the human breakpoint if the downstream action is consequential. |
| API / Webhook | External system calls a REST endpoint; a signature is passed in a request header and verified. | Always verify the signature. An unverified webhook endpoint is an unauthenticated command execution path into your estate, and it is one of the most common findings in an agent platform review. |
| User conversation | The ordinary entry point for conversational and flow agents. | Untrusted input by definition. Filter prompt injection at the boundary, not in the prompt. |
Human approval breakpoints
A breakpoint on the canvas holds execution before a core data operation until a named approver acts. Approvals can also be pushed into the enterprise OA or approval system, so the person confirms in the tool they already use and the agent continues on their decision rather than waiting in a queue nobody watches.
The condition is a business rule, not a formality. "Any write to the finance system" is too coarse; "single sync above a set amount requires finance approval" is the level at which it works.
Fallback to a human — and the trap in it
When intent-recognition confidence falls below a configured threshold, the request routes to a human queue, with the confidence threshold itself treated as a control that can be tuned per scenario.
Here is the trap, and it is a common one in production systems: the fallback branch is not mandatory to configure. An agent can be deployed with no fallback path at all, look completely healthy in testing, and then send genuinely ambiguous requests into the void on day one. This is the single most-frequently-missed configuration item we find, and it is why "does every agent have a defined low-confidence path, and has anyone tested it?" is on our go-live checklist.
Also worth knowing. Release review can itself be formalised — the approval process for publishing an agent can be put under managed review rather than left to individual judgement. And one reliability mechanism is yours to build, not ours: retries require a unique request identifier to prevent duplicate writes, which is an application-level responsibility. We design it with your developers rather than assuming the platform handles it.
Five questions that settle whether you need this
Five yes-or-no answers. If you cannot answer the first three, the capability is not your bottleneck yet.
- Can you name the specific workflow this serves — not the department?
- Can you name the person accountable when it is wrong?
- Can you show me historical cases where a human did this task, so we can build an evaluation set?
- Can you tell me what this capability explicitly will not do?
- Can you tell me what it costs per task, and how you would reduce that cost?
What the first ninety days look like
The same shape on every capability. The content differs; the checkpoints do not.
| By day 30 | By day 60 | By day 90 |
|---|---|---|
| Baseline captured on your metric | Workflow running with a named approver | Metric moved, against the baseline you did not choose |
| Scope boundary documented — including what it may not do | Evaluation harness re-running on every change | Decision log reviewed by your risk function |
| Historical cases assembled for testing | Training delivered, completion in the LMS | Next workflow scoped from what we learned |
| Data lineage for every source the agent reads | Cost per task measured and modelled | Evidence pack complete and accepted |
What this page answers
Every topic below is covered in the sections above, and each links to the page that goes deeper on it.
Bring the workflow you think needs an agent. We will draw it on the canvas.
A working session on one real process: nodes, state, memory mode, trigger, and every point where a human has to take over. You will leave with a diagram you can circulate internally.