Skip to content
Henry Rincón
CV (PDF)

Methods · Topic T2

How an agent system should be structured

It prints in full from the browser, on A4 or Letter.

Block 1

The problem

Structuring a multi-agent system that works in production, and being able to show, before and after putting it into production, that it works.

Summary in three lines

  1. A multi-agent system is structured from the process, not from the framework: every activity is specified with inputs, function, outputs and exceptions, and only the one that needs to interpret becomes an agent; the rest is code.
  2. The work is split among specialists with their own context, the state is saved at every step and autonomy is granted in proportion to risk: whatever cannot be undone is approved by a person.
  3. It is known to work because it is evaluated before going into production and afterwards: criteria that pass or fail, a case broken on purpose for every control, and the whole session observed across four dimensions.
Block 2

The map

The system at a glance: from the request to the person who approves

Swipe to see the whole map.

The system at a glance: from the request to the person who approvesA request reaches the orchestrator, which follows the graph set by the process contract and delegates to two specialists, each with its own context. One of them uses tools connected over MCP, with minimal permissions. Both write to a state that is saved step by step; code validators check it, and whatever cannot be undone goes to a person who approves. Every step leaves a record in the session traces, which are evaluated and reported to that same person.Request1Process contract2Orchestrator3Specialist A4Specialist B5Tools over MCP6Saved state7Code validators8Person whoapproves9Session traces10Evaluation11

Legend of shapes and colors

  • Actor — who does the work
  • Data — what is stored and read
  • Control — a rule that gets checked
  • Person — a person decides
  • External — what comes from outside

Reading the map, node by node

A request reaches the orchestrator, which follows the graph set by the process contract and delegates to two specialists, each with its own context. One of them uses tools connected over MCP, with minimal permissions. Both write to a state that is saved step by step; code validators check it, and whatever cannot be undone goes to a person who approves. Every step leaves a record in the session traces, which are evaluated and reported to that same person.

  1. Node 1 Request (External) — What arrives from outside: a question, a case, a document to process.
  2. Node 2 Process contract (Data) — The process drawn in BPMN with every activity opened up: what it receives, what it does, what it delivers and when it stops. The graph and the criteria come from here.
  3. Node 3 Orchestrator (Actor) — Follows the graph, hands out the work and gathers the results; it does not do the specialists’ work.
  4. Node 4 Specialist A (Actor) — Works inside its harness —the wrapper that sets its function, sources, tools and input and output contract— and receives only the context its task needs.
  5. Node 5 Specialist B (Actor) — Another specialist with its own harness; this one also uses external tools.
  6. Node 6 Tools over MCP (External) — Sources and actions connected through a shared protocol (MCP), enabled only if the task needs them and with minimal permissions.
  7. Node 7 Saved state (Data) — Every step is saved: work resumes after a failure or a pause. Long-term memory keeps decisions and lessons, not whole conversations.
  8. Node 8 Code validators (Control) — Whatever demands exactness is checked by code: a schema, a calculation, a citation that must exist. The model does not grade itself.
  9. Node 9 Person who approves (Person) — Approves, with an exact word, whatever cannot be undone; without that word, the system does not continue.
  10. Node 10 Session traces (Data) — The whole session: what was asked, with which context, what each specialist answered, how long it took, what it cost and how it ended.
  11. Node 11 Evaluation (Control) — Binary criteria and cases broken on purpose before release; afterwards, the whole conversation and the path step by step.

Connections

  • from Request to Orchestrator
  • from Process contract to Orchestrator (sets the graph)
  • from Orchestrator to Specialist A (delegates)
  • from Orchestrator to Specialist B (delegates)
  • from Specialist B to Tools over MCP (uses)
  • from Specialist A to Saved state (writes)
  • from Specialist B to Saved state (writes)
  • from Saved state to Code validators (checks)
  • from Code validators to Person who approves (the irreversible)
  • from Saved state to Session traces (leaves a record)
  • from Session traces to Evaluation (evaluated)
  • from Evaluation to Person who approves (reports)
Block 3

The phases

  1. Phase 1

    Specify the process

    Inputs

    • The business process, drawn in BPMN.
    • The decision or action the system must enable.

    Activities

    • Open up every activity: inputs, function, outputs, sources, tools and when to stop.
    • Write down the exceptions: missing information, a contradiction, a tool that does not respond.
    • Separate what needs interpretation (agent) from what demands exactness (code).

    Artifacts

    • The contract of each activity.
    • The list of exceptions, each with its response.
    Who decides
    The process owner, together with whoever builds.
    Control that closes the phase
    Every activity traces back to an element of the process; none is left without an owner.
    Evidence

    At Vesting, this breakdown —inputs, rules, sources, tools, outputs and when to call in a person— came before the eleven-stage core process that 27 agents were built with.

  2. Phase 2

    Split the work and set the autonomy

    Inputs

    • The contract of each activity.

    Activities

    • Decide whether one agent is enough or a graph of specialists is needed.
    • Give each activity a level: consult, recommend or execute.
    • Give each specialist only the sources and tools its task needs.

    Artifacts

    • The graph: who does what and what passes between them.
    • The autonomy level, written down per activity.
    Who decides
    The process owner; whatever is irreversible stays with a person.
    Control that closes the phase
    No irreversible action without a human approval point in the graph.
    Evidence

    At Vesting the three levels —consult, recommend, execute— were decided case by case and written down before building.

  3. Phase 3

    Build with contracts

    Inputs

    • The graph and the autonomy levels.

    Activities

    • Write each agent’s constitution: its laws, its commands and its sources.
    • Write acceptance criteria that pass or fail, with no judgment in between.
    • Prepare, for every control, a case broken on purpose that proves it fires.
    • Solve with code whatever demands exactness: calculations, formats, queries.

    Artifacts

    • Each specialist’s harness.
    • The binary criteria and their bait, the broken case for each control.
    Who decides
    Whoever builds, within the contract.
    Control that closes the phase
    Every control is seen failing on its broken case before it is accepted.
    Evidence

    That is how the eleven agents in this site’s portfolio that run on Claude Code are born: a constitution in a CLAUDE.md, the harness with its binary criteria —20 in the Power BI Dashboard Builder, 44 in the Computational Paper— and a bait case for each control.

  4. Phase 4

    Evaluate before putting it into production

    Inputs

    • The built agent and its criteria.
    • Usual scenarios, known exceptions and edge conditions.

    Activities

    • Run the scenario battery against the criteria.
    • Compare against a declared baseline, with the same sample and the same metric.
    • Check that the agent abstains or hands the case over when the evidence falls short.
    • Test the handoffs between specialists, not just each one on its own.

    Artifacts

    • The criteria report: which pass and which do not.
    • The comparison with the baseline: sample, metric and result.
    Who decides
    Whoever answers for the result, with the definition of done agreed at the start.
    Control that closes the phase
    What was written down is judged, not whether the agent “looks good”.
    Evidence

    With ARKHÉ, 120 scenarios were compared against a generalist agent that received everything on every run: in the author’s own measurements, 52% fewer tokens and instruction compliance from 71% to 93%, with no published artifact.

  5. Phase 5

    Operate and learn

    Inputs

    • The released agent.
    • The events of every session.

    Activities

    • Rebuild the whole session: request, context, response, time, cost and final state.
    • Look at four dimensions at once: operational, usage, economic and functional.
    • Turn every failure into a new case in the battery.

    Artifacts

    • Operations dashboards per agent.
    • New cases for the next evaluation.
    Who decides
    Product and operations, with the dashboard in front of them.
    Control that closes the phase
    A signal warns before the user notices.
    Evidence

    At Vesting the platform came to watch up to 23 agents at once, in real time, with the session as the unit of analysis and those four dimensions.

Block 4

The design decisions

  1. One agent or a graph of specialists

    When yes
    When the tasks need different contexts, sources or tools, or can run in parallel.
    When no
    When every step shares the same context or depends heavily on the others: there, splitting only adds cost.

    Why

    State of the field

    According to Anthropic, a multi-agent system spends about fifteen times the tokens of a chat, and domains where all agents share the same context or depend heavily on one another are not a good fit today.[1]

    Evidence

    ARKHÉ avoids the generalist agent that receives all the knowledge, all the tools and all the responsibilities: it splits the work among specialized capabilities with explicit coordination rules.

  2. What is an agent and what is code

    When yes
    An agent, when the task needs to interpret, synthesize or coordinate flexibly.
    When no
    When the task demands exactness, repeatability or an unambiguous check: a calculation, a format, a query.

    Why

    State of the field

    Microsoft puts it in writing in its Agent Framework documentation: if you can write a function to handle the task, do that instead of using an agent.[2]

    Evidence

    In the Tax Expert, the arithmetic runs in Python with Decimal and the model never touches a figure; in the Power BI Dashboard Builder, every DAX measure is tested with a query before moving to the next phase.

  3. Where the state lives

    When yes
    Saved state, when the work outlasts a conversation, can fail halfway, or has to wait for a person.
    When no
    When everything finishes in a single pass and rerunning it costs less than saving it.

    Why

    State of the field

    LangGraph 1.0 persists execution state automatically and lets a run pause so a person can review, modify or approve, then resume from there.[3]

    Evidence

    In ARKHÉ memory is designed by function: decisions that persist, reusable results, temporary context and detail that is discarded; in the published agents it takes the form of a log, lessons from each run and recorded architecture decisions.

  4. How much autonomy, and where it stops for a person

    When yes
    Let it act alone when the action is reversible, verifiable and low-impact.
    When no
    When the consequence is significant, hard to reverse or hard to observe: there the agent recommends and a person decides.

    Why

    State of the field

    OWASP calls it excessive agency when an agent gets more functions, permissions or autonomy than it needs, and recommends human approval for high-impact actions and authorization enforced in the downstream system, not left to the model’s judgment.[4]

    Evidence

    In the author’s agents the approval point is mechanics, not a reminder: the agent stops until the person types a literal word. The Power BI Dashboard Builder has 5 of those gates.

  5. From BPMN to orchestration

    When yes
    When the process already exists and is approved: the diagram is the best starting specification for the graph.
    When no
    When the task is open-ended and has no defined steps: an invented diagram only gives false precision.

    Why

    Judgment

    A diagram shows the sequence, but not what each activity receives, transforms and delivers. If the process is approved, what runs must trace back to it box by box; otherwise, what was approved and what runs drift apart without anyone noticing.

    Evidence

    FORJA, one of the author’s research lines, opens up every BPMN activity with inputs, function and outputs and compiles the diagram into an orchestration of agents that preserves the BPMN structure: in the sealed paper it preserved 99.5%, and the only element out of 204 left untraced was outside the specified subset.

  6. How a result is judged

    When yes
    A binary criterion, when the result can be checked: a format, a cited source, a well-chosen tool, a correct abstention.
    When no
    When the criterion is fuzzy: there a model acting as judge helps, calibrated against a person’s judgment and never as the only control.

    Why

    State of the field

    Anthropic describes three ways for an agent to verify its work —rules, visual feedback and a model acting as judge— and warns that the judge is generally not a very robust method.[5]

    Judgment

    A criterion that passes or fails is better than a score from 1 to 5: a score gets argued over; a criterion is either met or not.

  7. Which model for each step

    When yes
    A large model, for the step that coordinates, plans or reasons over a lot of information.
    When no
    For bounded, repetitive steps: there a small model is enough and costs less.

    Why

    State of the field

    The model router in Microsoft Foundry (formerly Azure AI Foundry) uses smaller, cheaper models when they are enough and keeps the larger ones for complex work; Anthropic’s research system leads with a larger model and delegates to subagents running a smaller one.[6][1]

    Evidence

    In ARKHÉ the savings did not come from a cheaper model: in the author’s own measurements, the 52% fewer tokens came from sending less useless context on every call.

Block 5

What is new in 2026

  • State of the field

    Durable execution: state saved at every step

    What changes from common practice

    Long-running work survives a failure or a wait for a person and resumes from the last saved step instead of starting over. LangGraph 1.0 persists state automatically, and Agent Framework 1.0 offers it in its workflows through checkpoints.[3][7][1]

    Judgment

    The rule: if a step is going to wait for a person, the state is saved before asking.

  • State of the field

    Context engineering, not just prompt engineering

    What changes from common practice

    The question stops being how to word the instruction and becomes what goes into each call’s context. Context is treated as a finite resource: it is compacted when it fills up, written to notes outside the window, and split among subagents with clean contexts that hand back only a summary.[8][5]

    Evidence

    It is the idea ARKHÉ works with: no component receives information just because it is available; it receives what its task needs, retrieved from authorized sources.

  • State of the field

    Shared protocols: MCP for tools, A2A between agents

    What changes from common practice

    A tool is connected once through a standard and agents from any framework can use it; servers are found in an open registry, and agents on different platforms can talk to each other. In its July 2026 revision, MCP became stateless and moved long-running tasks into an official extension.[9][10][11]

    Evidence

    The Power BI Dashboard Builder creates measures, columns and relationships through the modeling MCP server, testing every measure in DAX before moving on.

  • State of the field

    Evaluating the whole conversation and the path, not just the answer

    What changes from common practice

    What is tested before release only covers what was anticipated; so evaluation continues in production over the whole conversation —did the agent reach the goal?— and over the process step by step: which tool it chose, with which parameters, and what it did with the result.[12][13]

    Evidence

    At Vesting the session was already the unit of analysis: it was rebuilt event by event to see at what point an interaction had gone off course.

  • State of the field

    End-to-end traces with OpenTelemetry

    What changes from common practice

    The agent’s trace travels over the same open standard as the rest of the system, so a failure can be followed from the request to the tool even when it crosses frameworks and servers.[14][9][7]

  • State of the field

    Frameworks that converge, and a platform that hosts them

    What changes from common practice

    Microsoft merged Semantic Kernel and AutoGen into Agent Framework 1.0, with graph-based workflows, human approvals, MCP and A2A. Microsoft Foundry hosts agents written with it or with LangGraph and gives each one its own identity, with session state and observability managed for it.[7][15]

    Evidence

    At Fundación CTIC, Microsoft Agent Framework and the Claude Agent SDK are used for experimentation and prototypes; the author works there with the LangChain ecosystem alongside n8n.

  • State of the field

    Excessive agency as a front-line risk

    What changes from common practice

    In the announcement of its 2026 Top 10 for LLM applications, OWASP reports, through a contributor to the project, that excessive agency is now number three (it was LLM06 in the 2025 edition): giving an agent more functions, permissions or autonomy than it needs now ranks among the top three risks on the list.[16][4]

Block 6

Failure modes and how to anticipate them

  • What breaks
    The agent answers, but does not resolve
    How it shows up
    Sessions that end without the expected state, or with a person stepping in.
    Control that catches it
    The functional dimension of monitoring: final states and sessions that needed intervention, per agent.
  • What breaks
    The context fills up with noise
    How it shows up
    Tokens per completed task go up while compliance does not.
    Control that catches it
    Tokens per completed task measured together with instruction compliance, against the baseline.
  • What breaks
    A specialist hands the next one something incomplete
    How it shows up
    Every piece passes its tests and the whole fails.
    Control that catches it
    Input and output contracts between specialists, with tests of the handoff and not only of each one.
  • What breaks
    The agent does more than it was supposed to
    How it shows up
    An action with consequences shows up in the traces without an approval next to it.
    Control that catches it
    Minimal permissions per specialist and an approval point with a literal word before anything irreversible.
  • What breaks
    The model makes up a figure or a source
    How it shows up
    A verifiable claim without the passage that supports it.
    Control that catches it
    An authorized source or a declared gap: a validator rejects any output that cites what does not exist.
  • What breaks
    A control that never fails
    How it shows up
    A test that is always green and that nobody has ever seen turn red.
    Control that catches it
    A bait case for every control: the case broken on purpose that proves it fires.
  • What breaks
    Cost grows silently
    How it shows up
    Retries, abandoned sessions or mass re-reads that produce nothing.
    Control that catches it
    Token cost per session and per agent, seen next to what it resolves, with a written threshold for each pattern.
  • What breaks
    An instruction sneaks in through a tool
    How it shows up
    A text read from a page or a document asks the agent to do something.
    Control that catches it
    What a source says is data, not an instruction: it is ignored and logged, and authorization lives in the downstream system.
Block 7

Metrics and controls

  • What is measured
    Acceptance criteria met
    Threshold
    All green: a binary criterion is not negotiable.
    Who approves the step to production
    Whoever answers for the result, against the definition of done agreed at the start.
  • What is measured
    Controls with a bait case that fires
    Threshold
    Every critical control; any control without one is declared as such.
    Who approves the step to production
    Whoever builds, reviewed by someone who did not build.
  • What is measured
    Instruction compliance on the scenario battery
    Threshold
    Equal to or better than the declared baseline, on the same sample.
    Who approves the step to production
    Whoever answers for the result.
  • What is measured
    Tokens per completed task
    Threshold
    No worse than the baseline, and never at the expense of compliance.
    Who approves the step to production
    Whoever pays for the operation.
  • What is measured
    Correct abstentions
    Threshold
    In every case without evidence, the agent declares the gap or hands the case over; a single made-up fact stops the release.
    Who approves the step to production
    The process owner.
  • What is measured
    Sessions that needed human intervention
    Threshold
    Below the cap agreed for the version; if it goes over, the version goes back to evaluation.
    Who approves the step to production
    Product and operations, with the dashboard in front of them.
  • What is measured
    Irreversible actions without approval
    Threshold
    Zero.
    Who approves the step to production
    The process owner.

The thresholds are examples of the method, not figures from a specific project.

Block 8

Evidence from projects

  • EvidenceLevel: Real use

    Vesting: 27 agents in production

    The eleven-stage core process that a startup used to build 27 agents for 12 clients on n8n was defined, documented and validated, and the platform that came to watch 23 at once, in real time, was designed in Microsoft Fabric.

    See where
  • EvidenceLevel: Real use

    ARKHÉ: the author’s agentic ecosystem

    Specialized harnesses that set each agent’s function, sources, tools and contract. In the author’s own measurements over 120 scenarios, against a generalist: 52% fewer tokens and instruction compliance from 71% to 93%. It is for personal use; it is not presented as production.

    See where
  • EvidenceLevel: Prototype

    FORJA: from BPMN to an orchestration of agents

    FORJA is one of the author’s research lines: a compiler that turns a process drawn in BPMN into an orchestration of agents. From the BPMN it preserves the structure —every activity is opened up with inputs, function and outputs, and every element traces to its realization—: in the sealed paper it preserved 99.5%. Verifiers from different families watch for conformance. The demonstrator exists.

    See where
  • EvidenceLevel: Real use

    The portfolio agents, on Claude Code

    Twelve work systems with a constitution, a harness, binary criteria, bait cases and human gates with a literal word; five are sealed. They are for personal use, with deliverables and evidence.

    See where
  • EvidenceLevel: Real use

    Power BI Dashboard Builder

    Creates measures, columns and relationships through the modeling MCP server, testing every measure in DAX, and writes the report in Power BI’s native JSON; 20 criteria and 5 human gates, and no run closes without a person approving the render.

    See where
  • EvidenceLevel: Real use

    ISO 42001 Expert

    Every normative claim cites clause and page or declares the gap, and no ruling with consequences moves forward without a person’s approval. It is the one used in Fundación CTIC’s AI strategy, in the initial version (v1.0.0) of its technical sheet.

    See where
  • EvidenceLevel: Real use

    LangChain, LangGraph, LangSmith and Langflow

    Together with n8n, they are the agent frameworks used at Fundación CTIC. That work has no deliverable published on this site.

    See where
  • EvidenceLevel: Prototype

    Microsoft Agent Framework and Claude Agent SDK

    They are used for experimentation and prototypes at Fundación CTIC.

  • EvidenceLevel: Real use

    This site’s chat

    It retrieves from the corpus, cites what it retrieved and, if it finds nothing, says so. Since September 2026 it keeps one row per answer: who asked, what was answered, with which sources, with which provider, how many tokens and how many milliseconds.

Block 9

Limits and scope

  • Evidence

    The word “production” is reserved for the 27 agents at Vesting. The ones in ARKHÉ and in the portfolio are personal-use work systems: they have had no users other than their author.

  • Evidence

    The ARKHÉ figures are the author’s own calculations, with no published artifact: they measure less useless context and more adherence to the specification, not quality in the abstract, and they cannot be compared with another ecosystem without rerunning the same scenarios.

  • Evidence

    With Microsoft Agent Framework and the Claude Agent SDK there has been experimentation and prototypes, not production. The author works with the LangChain ecosystem at Fundación CTIC, with no deliverable published here.

  • Evidence

    The author has not run agents in containers: Docker and Kubernetes in production are not part of the author’s professional experience.

  • Evidence

    With Microsoft Foundry, the experience is the provider adapter in this site’s chat and studying for the AI-103, which is in progress; an agent system hosted there is not part of the author’s experience.

  • Evidence

    FORJA has its demonstrator —compiler, five processes, baseline and approval gates—, but whether professionals use it can only be shown with professionals, and that test is still missing.

  • Judgment

    What should be done differently today: traces on an open standard from the very first agent, so a session can be followed even when it crosses frameworks, and the whole conversation evaluated online, not only before release.

  • Judgment

    And it is better not to start with a graph of many agents: start with one, measure it against a baseline and only split the work where context or parallelism justify it.

Block 10

Sources and review date

  1. [1]
    How we built our multi-agent research system

    Anthropic ·

    https://www.anthropic.com/engineering/multi-agent-research-system

  2. [2]
    Microsoft Agent Framework Overview

    Microsoft Learn ·

    https://learn.microsoft.com/en-us/agent-framework/overview/

  3. [3]
    LangChain and LangGraph Agent Frameworks Reach v1.0 Milestones

    LangChain ·

    https://www.langchain.com/blog/langchain-langgraph-1dot0

  4. [4]
    LLM06:2025 Excessive Agency (OWASP Top 10 for LLM Applications 2025)

    OWASP GenAI Security Project ·

    https://genai.owasp.org/llmrisk/llm062025-excessive-agency/

  5. [5]
    Building agents with the Claude Agent SDK

    Anthropic ·

    https://claude.com/blog/building-agents-with-the-claude-agent-sdk

  6. [6]
    Model router for Microsoft Foundry concepts

    Microsoft Learn ·

    https://learn.microsoft.com/en-us/azure/foundry/openai/concepts/model-router

  7. [7]
    Microsoft Agent Framework Version 1.0

    Microsoft ·

    https://devblogs.microsoft.com/agent-framework/microsoft-agent-framework-version-1-0/

  8. [8]
    Effective context engineering for AI agents

    Anthropic ·

    https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents

  9. [9]
    Model Context Protocol specification 2026-07-28: Key Changes

    Model Context Protocol ·

    https://modelcontextprotocol.io/specification/2026-07-28/changelog

  10. [10]
    Introducing the MCP Registry

    Model Context Protocol ·

    https://blog.modelcontextprotocol.io/posts/2025-09-08-mcp-registry-preview/

  11. [11]
    Linux Foundation Launches the Agent2Agent Protocol Project to Enable Secure, Intelligent Communication Between AI Agents

    Linux Foundation ·

    https://www.linuxfoundation.org/press/linux-foundation-launches-the-agent2agent-protocol-project-to-enable-secure-intelligent-communication-between-ai-agents

  12. [12]
    Improve agent quality with Insights Agent and Multi-turn Evals, now in LangSmith

    LangChain ·

    https://www.langchain.com/blog/insights-agent-multiturn-evals-langsmith

  13. [13]
    Agent Evaluators for Generative AI

    Microsoft Learn ·

    https://learn.microsoft.com/en-us/azure/foundry/concepts/evaluation-evaluators/agent-evaluators

  14. [14]
    Introducing End-to-End OpenTelemetry Support in LangSmith

    LangChain ·

    https://www.langchain.com/blog/end-to-end-opentelemetry-langsmith

  15. [15]
    Hosted agents in Foundry Agent Service

    Microsoft Learn ·

    https://learn.microsoft.com/en-us/azure/foundry/agents/concepts/hosted-agents

  16. [16]
    OWASP GenAI Security Project Unveils 2026 Top 10 for LLM Applications, New Agent Control Standard and Sponsors as Community Tops 30,000 Members

    OWASP GenAI Security Project ·

    https://genai.owasp.org/announcement/owasp-genai-security-project-unveils-2026-top-10-for-llm-applications-new-agent-control-standard-and-sponsors-as-community-tops-30000-members/