Manifesto · Interactive Agents
Enterprise AI agents need both rigour and adaptability. The frameworks the industry ships make you pick one.
Production AI in regulated environments has to behave reliably when a compliance rule must fire, and converse fluidly when a customer goes off-script. Both, in the same session, often in the same turn. The dominant agent paradigms (monolithic system prompts, intent-routed workflow graphs, packaged skills) each compromise one for the other. Interactive Agents are the architecture that refuses that compromise.
This document is the design rationale. It defines what an Interactive Agent is, the eight components that compose it, the per-turn evaluation engine that makes its behaviour enforceable, the control-adaptability spectrum that lets one agent hold both ends at once, and the continuous-improvement loop that turns every interaction into compounding operational IP.
We did not start from the question “how do we make an LLM more useful.” We started from the question “what would have to be true for an enterprise to trust an LLM with production work?” The architecture is the answer.
Bernardo Branco
Co-Founder & Chief AI Officer · InteractiveAI
02 · The problem
The dominant paradigms each fail at the same point.
AI agents have to handle interactions where anything can happen. Humans pivot, ask multi-part questions, and backtrack. Enterprise systems fire concurrent events, produce unexpected data states, and chain dependencies across dozens of services. Existing frameworks force a choice between rigid control that breaks the moment an interaction deviates from the expected path and flexible agents that can't be trusted to follow the rules.
Three paradigms dominate the field. They differ in surface mechanics but converge on the same architectural gap.
System Prompt Agents
Every business rule sits in one monolithic prompt. As logic accumulates, the model suffers instruction fatigue: it cannot weigh competing priorities. Reliability degrades. The behavioural surface is fully exposed to adversarial probing on every call.
Workflow-Driven FrameworksIntent-classification + fixed routing
Classify user intent, then route through a pre-determined node sequence. Effective for strictly sequential tasks. They break the moment a user pivots, asks compound questions, or backtracks. Once the model is inside a node, there is minimal influence over how it generates that node's output.
Skills-Based ApproachesModular instruction packs (e.g., Anthropic Agent Skills)
Modularise expertise into packaged instruction sets loaded when relevant. Improves organisation, not execution. The model decides what to read and how to follow it. No evaluation engine for which rules apply now; no step-level diagnostics; token cost scales with skill complexity.
The Shared Failure
Across all three paradigms, the same gap: no granular governance. No real-time, localised enforcement over model generation at the exact moment of execution. Without that, every claim about reliability is aspirational.
03 · The approach
Dynamic Context Engineering.
Interactive Agents abandon both the monolithic system prompt and the rigid routing graph. The architecture operates on one core principle: at every turn of an interaction, a structured evaluation engine assesses the exact micro-state of the current interaction and dynamically assembles only the precise behavioural rules required for that specific moment. Not the full library. Not a routed slice. The exact subset.
This mechanism dismantles the failures of legacy approaches structurally, not aspirationally. Four claims follow from it:
- 01
Cure instruction fatigue.
Rather than loading every business rule into a bloated prompt, the engine matches the current interaction state and injects only the policies that apply to this turn. The model stays focused because it is never handed the whole rulebook at once, only the exact subset the moment requires.
- 02
Eliminate rigid routing.
Because context is assembled dynamically per turn, users are never forced down siloed, pre-determined branches. A compound question or an abrupt topic change activates multiple relevant policies simultaneously: the framework natively handles non-linear human behaviour.
- 03
Structurally enforce on every turn.
LLM guesswork is replaced with a structured evaluation pipeline. High-criticality rules (compliance, safety constraints, security protocols) are matched by the engine, not recalled by the model. Enforcement becomes a property of the pipeline, deterministic and repeatable, rather than something the model is asked to remember under load.
- 04
Close the improvement loop.
Every model decision traces back to the matched policies and the routine step that drove it. When the agent errs, domain experts don't touch code or rewrite a fragile master prompt; they adjust the natural-language policy responsible for the error and deploy the fix.
04 · The operating range
One agent. Both ends of the spectrum.
Decoupling behavioural rules from rigid workflows produces a unique architectural property: the ability to move freely along the control-adaptability spectrum, and to position different parts of the same agent at different points on it simultaneously.
High-control routines (KYC verification, withdrawal processing, regulatory disclosures) use detailed state diagrams with explicit conditional transitions for near-deterministic execution. Flexible policies (general inquiries, open-ended troubleshooting) use simple condition-action rules that give the model wide latitude to converse naturally. Both coexist in the same agent. An Interactive Agent can converse fluidly, snap into a tightly controlled compliance routine when requested, and transition back to open dialogue the moment the routine is complete.
The control-adaptability spectrum
High-control routines
KYC verification · withdrawal processing · compliance flows. Detailed state diagrams · explicit conditional transitions · near-deterministic execution.
Flexible policies
General inquiries · open-ended troubleshooting. Simple condition-action rules · model has wide latitude · converses naturally.
Both coexist in the same agent. Snap into a tightly-controlled flow, transition back to open dialogue, without breaking the framework.
Choosing between determinism and adaptability is a framework problem, not a business problem. We treat the spectrum as the unit of design: every agent is positioned on it per task, not per architecture.
Bernardo Branco · Co-Founder & Chief AI Officer
05 · Definition
What an Interactive Agent is.
An Interactive Agent is an LLM-powered agent that processes interactions by dynamically evaluating its core instructions at every decision point, deciding its next action in real time rather than following predefined conversation flows.
The framework is domain-agnostic. The same components compose into entirely different agents: the parts do not change, only what each one is authored to hold.
Assembled
CONTEXT
WINDOW
Policies
Atomic behavior unit
Variables
Customer context
Prompts
System prompt
Tools
External connections
Macros
Reusable snippets
Knowledge Base
Retrieved knowledge
Glossary
Domain dictionary
Routines
Multi-step SOPs
Message arrives
Eight components
All eight are scoped to an agent. The evaluation engine assembles them per turn, never all at once.
- 01
Prompts
- The agent's persistent identity and behavioural baseline: name, tone, language, response format, operational guardrails. Scoped to the pipeline stages where they apply, not loaded indiscriminately into every call.
- 02
Policies
- The atomic unit of behaviour. Each policy pairs a condition with an action. The evaluation engine assesses all policies against interaction state and injects only the applicable ones per turn. High-criticality policies (safety, compliance) are fully matched every turn they are in scope, and a policy can also list a tool to be re-matched after that tool runs, structurally enforced by the engine rather than relying on the model to remember them. This per-turn re-matching is the canonical guarantee the rest of this document builds on.
- 03
Routines
- Multi-step SOPs modelled as directed graphs of states and transitions. Adaptive traversal (backtracking by re-entering an earlier routine node, plus next-step selection) plus adjacent-only visibility, so the model only sees its current state and immediate options. Keeps long multi-step processes tractable and reduces drift.
- 04
Glossary
- Shared vocabulary. Grounds the agent's interpretation of user input and ensures policy conditions are read consistently across every component.
- 05
Macros
- Reusable blocks of authored message text, written once and interpolated by name wherever the agent needs consistent wording: a canned disclosure, a fixed escalation message, a regulator-approved phrasing reproduced verbatim. Authoring the text once prevents the drift that comes from re-typing approved language across dozens of touchpoints.
- 06
Variables
- Contextual state across interactions: customer attributes, session data, account flags, risk scores. Transforms generic policies into data-driven, personalised rules.
- 07
Tools
- External API connectors, served over MCP. Tools only enter context when a relevant policy activates, eliminating false-positive tool calls. Consequential tools (payments, deletes) pass through stricter validation than non-consequential ones. Because tools are served over MCP, Interactive Agents compose with the emerging tool-integration ecosystem rather than replacing it.
- 08
Knowledge Base
- The authored retrieval surface that grounds the agent's answers in the operator's own documents (help-centre articles, product documentation, policy texts) rather than the model's parametric memory. Optional by construction, and governed for residency, freshness, and index scope. One input source the engine composes against per turn, never a substitute for the glossary or for authored policies.
06 · Runtime
What happens on every turn.
When an input arrives, the agent does not generate an output from a static prompt. A structured pipeline evaluates the current interaction state and assembles the right context before the model acts. Much of what happens behind the scenes is determining which policies should apply at this exact moment: this is where the framework's core intelligence lies.
Worked example · compound request
A customer writes: “I need to cancel my subscription, and also check if my last invoice was correct.” A workflow framework has to route to one topic and drop the other, or pre-define every compound branch. An Interactive Agent activates the cancellation policies and the billing policies simultaneously, loads both into the same context window, and composes a response grounded in all of them.
The stages below are what that single turn runs through, in order.
- 01
Policy Matching
All policies are evaluated against the current interaction state. Only those whose conditions match are loaded into context, and their actions are assembled into the prompt. When matched rules conflict, pairwise priorities decide which instruction wins before anything reaches the model.
- 02
Routine Evaluation
For each active routine, the model evaluates its current position and immediate transitions with adjacent-only visibility, not the whole graph. A parallel check determines whether the latest input reverses a previous decision and requires re-entering an earlier routine node; if it fires, it takes precedence over forward progression.
- 03
Tool / Think Execution
Tools associated with matched policies are evaluated for applicability, parameter availability, redundancy, and fit, then served over MCP. Consequential tools pass through stricter validation. Results are cached in the session store.
- 04
Preparation Loop
If tools ran, the engine iterates again: matching, routine evaluation, and execution repeat against the updated state, up to max_engine_iterations (default 5), before the reply is drafted.
- 05
Response Generation
The model produces the customer-facing reply in a single chat-model call, grounded in exactly the context the engine assembled for the turn: the matched policies, routine state, tool results, glossary, and retrieved knowledge.
- 06
Event Emission
The turn's outcome is emitted and captured as a trace, recording the matched policies and the routine step so behaviour can be replayed and reviewed.
Every step is logged: which policies matched and why, which routine state was selected, what tools were called with what parameters, and the agent's rationale at each decision point. Every trace is interpretable, designed not as a debugging afterthought but as the primary mechanism for governance, quality assurance, and iterative improvement.
07 · Differentiators
Eight dimensions, three architectures.
Where the three architectures land on the dimensions that determine whether an agent is enterprise-ready.
Most agent comparisons reduce to a feature checklist. The dimensions that actually matter are the ones that determine whether a CISO will sign the deployment.
Bernardo Branco · Co-Founder & Chief AI Officer
Read each row across: the two left columns show where the prevailing architectures break, the right column shows how an Interactive Agent holds that dimension.
Read top to bottom, the pattern resolves: only the third architecture holds all eight.
08 · The engine
Structured reasoning, not free-form CoT.
Components define what the agent knows. The evaluation engine defines how that structure is exercised on every turn. It reads the current interaction state, decides which components apply, resolves conflicts, and drives the LLM through the steps required to produce a reliable output. Without it, an Interactive Agent would be indistinguishable from any other prompt-based system.
The engine runs a per-turn sequence of structured steps: it matches policies against the current interaction state, evaluates the active routines, makes the tool and reasoning calls the turn requires, and finishes with a single response-generation call. Each step is engineered around a specific decision, not left to free-form reasoning, so the same architecture executes the same way on every turn.
Free-form reasoning produces outputs whose structure varies from call to call. Attribution is impossible, and the model decides what to focus on, which in long contexts reliably means recent content wins. A structured engine solves this by design: each step has a defined shape, runs in a fixed order, and surfaces the exact decision it made.
Interpretability is the engine's natural side-effect. Every step is captured as part of the trace, not a logging layer retrofitted onto it. When an agent errs, the trace contains the exact step and the exact decision where the error originated. The fix is a targeted edit to the responsible component.
The per-turn pipeline
The per-turn pipeline, the same architecture described in §5, surfaced here at engine altitude.
Every turn
The Evaluation Engine
Match
Route
Tools
Loop
Respond
Emit
Policy Matching
stage 1 / 6The policies that apply to the current turn are matched and their actions assembled into the prompt. When matched rules conflict, pairwise priorities decide which instruction wins, no separate stage and no removal from context.
09 · Continuous improvement
The compounding flywheel.
The same architectural properties that make the framework reliable at runtime (discrete policies, traceable decisions, modular routines) make improvement tractable at scale. When every behaviour is attributable to a specific, editable artifact, fixing a problem becomes a targeted operation rather than a speculative prompt rewrite. Five mechanisms compound over time.
- 01
Traces
- Every interaction generates a hierarchical record: which policies matched and why, which routine states were entered, what tools were called with what parameters, and the model's reasoning at each decision point. Root-cause analysis becomes tractable: a bad response walks back to the exact artifact that produced it.
- 02
Evaluators
- On the Platform's Improvement layer, evaluators run automated checks against traces, rule-based, LLM-as-judge, or ground-truth comparison against a curated golden set, turning regressions into regression tests. Evaluators continuously score interactions; proposed changes are scored against the existing suite before deployment.
- 03
Policy & Routine Updates
- Fixes are direct edits to the responsible artifact in natural language. No code, no engineering bottleneck, no full redeployment. Iterate one component at a time so improvements remain attributable; test against the evaluator suite and historical traces before going live.
- 04
Memory
- Concrete, retrievable examples (positive exemplars, negative exemplars, contextual notes, account precedents) stored in a vector store and surfaced when structurally relevant. Tagged by the components active when they were created, so retrieval is targeted, not generic similarity. Authored by humans, the Copilot autonomously, or the Copilot with human approval. Memory shares the retrieval substrate with the policy library, but plays a different role: policies are prescriptive (their action enters the prompt directly), memories are illustrative (they show the model how a similar situation has been handled).
- 05
The InteractiveAI Copilot
- An autonomous agent whose job is to improve other agents. Reads traces, evaluator outputs, and annotation queues; identifies patterns no human could spot across thousands of interactions; suggests or directly edits policies, routines, and memories; proposes new evaluators when it detects quality dimensions the existing ones miss.
These mechanisms are not independent; they reinforce one another. Traces feed evaluators. Evaluators surface regressions and validate fixes. Fixes become policy and routine updates. Annotation queues label the edge cases. The Copilot synthesises everything into memory and proposes further improvements. Every interaction generates labelled data that strengthens the next iteration.
10 · Strategic value
Three assets that compound beyond the agent.
Two years into an Interactive Agents deployment, the runtime is not the only thing that has compounded. The artifacts the framework produces become assets in their own right.
Operational IP
Institutional knowledge, once locked in the heads of experienced staff, becomes structured, versioned, and executable. Policies and routines are organisational assets, not prompt artifacts.
Data Flywheel
Every decision generates labelled examples suitable for evaluation, memory curation, and, when it makes sense, fine-tuning smaller models for further cost and latency gains.
Cost & Model Portability
Pre-computed states, batched evaluation, smart routing. Precision retrieval keeps per-turn inference cost invariant to library size. Every model call goes through the LLM router, so the same architecture runs across frontier APIs and smaller open-weight models, with fallbacks: the model mix is yours to choose.
Security compounds the same way. In most architectures the attack surface grows with the rulebook: every rule added is another rule exposed on every call. Here it moves the other way. Because assembly exposes only the rules a turn needs, the library can grow for years while any single turn still presents a small, bounded surface to probe. The asset gets larger; what an attacker can reach does not.
11 · Close
The agent that ships on day one is the weakest version of the agent that will ever run in production.
Bernardo Branco · Co-Founder & Chief AI Officer
Every interaction after day one makes it better, provided the architecture was built around the loop, not retrofitted to enable it. The mechanisms above are how that happens.