# Agents and orchestration
canonical_url: https://www.3.14financialcontents.com/en/solutions/agents-and-orchestration/
markdown_url: https://www.3.14financialcontents.com/en/solutions/agents-and-orchestration/index.md
language: en
content_type: solutions
status: published
description: Flexible reasoning inside operations with state, contracts and accountability.

## What the orchestration preserves

- the objective
- the state
- the available tools
- the permissions
- the previous decisions
- the dependencies
- the waits
- the budgets
- the interventions
- the completion criterion

## Result

A minimal composition of models, agents, tools, workflows and people that offers continuity and control: each application uses only the objects it needs, and the architecture declares what each one may propose, decide and execute.

An agent contributes interpretation and choice. Orchestration turns that capacity into work that is continuous, bounded and examinable.

## Principle

A multi-agent architecture adds value when specialisation, parallelism or independent review outweigh the cost of coordination.

## Qué podemos enseñar

- **Cómo funciona** — Behaviour is represented as a graph of states, nodes, transitions, conditions, checkpoints and exit criteria, built with LangGraph, PydanticAI or architectures of our own. Every tool declares inputs, outputs, identity, permissions, effects, cost, latency, errors, idempotency and reversibility through typed contracts with Pydantic, exposed where appropriate through MCP and FastMCP. Durable workflows — Hatchet and other durable execution engines — persist state, waits, retries, timeouts and resumption on top of PostgreSQL, pgvector and NATS/JetStream. Memory is separated into layers (interaction, case, project, domain and improvement), each with its own scope, provenance, period of validity and forgetting policy. A router chooses the model according to difficulty, modality, language, cost, latency, privacy and observed quality, and every path carries a budget and a stopping criterion.
- **Qué podemos mostrar** — The graph of a path and the trace of a complete execution can be examined: what context was retrieved, which tools were declared and with what permissions, what decision the agent took at each branch, which model was routed to and at what cost, where a person intervened and with what evidence their judgement was requested, how a failure was recovered and which completion criterion closed the case. So can a tool's contract, the authorisation policy that governs it and the memory layers with their provenance and their period of validity.
- **Cómo se evalúa** — We evaluate paths, not only answers. Result: whether the task reaches its completion criterion. Path: whether the tools, sources and decisions were appropriate. Policies: whether the agent respected permissions, limits and authorisations. State: whether it preserved and updated the context correctly. Efficiency: cost, latency, steps, redundancy and coordination. Recovery: behaviour in the face of failures, duplicates, late events and incomplete routes. Abstention: the ability to recognise a lack of information, authority or tools. Human intervention: quality of the context and usefulness of the decision requested. Multi-agent: attribution, consistency, conflicts and the added value of the specialisation. Evaluation systems, DSPy and GEPA are used to measure and optimise those paths, adverse cases included.
- **Límites** — Agents are useful when there is contextual variety and a bounded set of tools; rules and deterministic software keep the constraints that need reproducibility and control. A multi-agent architecture only pays off when specialisation, parallelism or independent review outweigh the cost of coordination, which is also a possible source of error. Authority is distributed by action and consequence: the irreversible needs permissions, limits and intervention proportionate to the risk. And no orchestration corrects an ambiguous definition of the result or an organisational policy that does not yet exist.
- **Estado** — operational

An agent adds value when the next step depends on the context.

It can interpret a request, gather information, compare alternatives, choose a tool, formulate a bounded plan or ask a person for judgement.

Orchestration turns those local decisions into a system able to keep going.

We build agents as specialised components inside an architecture that maintains accountability and observability.

## Five different objects

Clarity improves when we distinguish:

**Model.** It produces an inference, a classification, a generation or a choice.

**Agent.** It uses context and a model to choose among permitted tools or paths.

**Tool.** It queries, calculates or executes through a defined contract.

**Workflow.** It preserves states, dependencies, events, waits, retries and recovery.

**Orchestrator.** It distributes work, connects participants and maintains a view of the complete path.

An application may need only some of them. The architecture chooses the minimal composition that offers continuity and control.

## Typed tools

Every tool declares name and function, inputs, outputs, identity, permissions, effects, cost, latency, errors, idempotency, reversibility and observability.

The agent receives a limited, comprehensible capability: it uses tools declared through contracts, permissions and known effects.

Contracts make it possible to validate before executing, to simulate, record, limit, replace, test and present the action to a person.

MCP and FastMCP can offer a common interface for exposing tools and resources. Business policy and authorisation stay in components the organisation can govern.

## Graphs and paths

We represent behaviour through states, nodes, transitions, conditions, routes, tools, handovers, checkpoints and exit criteria.

LangGraph, PydanticAI and architectures of our own can be used depending on the type of path.

A graph makes it possible to combine deterministic zones and open choices. For example:

```text
REQUEST
   ↓
IDENTIFY CASE
   ↓
RETRIEVE CONTEXT
   ↓
VALIDATE CONDITIONS
   ├── sufficient information → PROPOSE ACTION
   ├── a datum is missing      → REQUEST INFORMATION
   └── exception               → ASK FOR JUDGEMENT
                                   ↓
                              EXECUTE TOOL
                                   ↓
                              VERIFY RESULT
```

The agent can interpret and choose within routes; the workflow preserves the process.

## Bounded memory

Memory serves different functions.

**Interaction memory.** The context needed to understand the current conversation.

**Case memory.** The state, decisions, evidence and next steps of an operation.

**Project memory.** Questions, decisions, dependencies and work that must survive across participants.

**Domain knowledge.** Concepts, rules, procedures and sources with a period of validity of their own.

**Improvement memory.** Exceptions, results and corrections that help to review the system.

Each layer has its own scope, permissions, provenance, version and forgetting policy.

Memory preserves objectives, decisions, states and dependencies with policies of scope, validity and forgetting, so that a policy in force stays separate from an obsolete conversation, and a local decision from general knowledge.

## Durable workflows

A process may wait for a person, a date, an event, an external response, a business condition or a physical signal.

Durable workflows preserve the state and make resumption possible.

Hatchet and other durable execution engines can supply persistence, workers, events, retries, timeouts, scheduling, observability and resumption.

The model steps in when there is a contextual decision. The workflow continues even if the model or the worker changes.

## Multi-agent systems

Several agents add value when there is a structural reason.

**Specialisation.** Each agent uses different tools, context or models.

**Parallelism.** Several lines of research or construction can advance independently.

**Separation of context.** A task may benefit from keeping specific memory and sources.

**Independent review.** A second agent examines the result under different criteria.

**Division of authority.** One agent proposes and another validates within explicit contracts.

We design so that every agent has a responsibility, an input, an output, tools, permissions, a budget, a stopping criterion and a relationship with the other participants.

Coordination is evaluated as a cost and as a possible source of error.

## People inside the orchestration

People can formulate objectives, supply context, validate an inference, decide a trade-off, authorise, correct, stop, review and change the policy.

The interface presents the state, the reason for the intervention, the evidence, the proposal, the alternatives, the consequences and the next step.

The human decision stays linked to the case and can feed a later review.

## Agents for software and research projects

In complex projects, agents can occupy functions such as coordination, analysis, research, programming, execution, documentation, testing, adversarial review and second opinion.

SuperPythagoras organises that work when people and bots share the project: it allocates roles, sets delivery contracts, orders the handovers and submits every change with consequences to SecondOpinion, a review independent of whoever wrote it.

SuperSocrates is the system that asks: it interrogates the project material to find gaps, information that does not match between sources, decisions that contradict each other and assumptions nobody wrote down, and proposes the next useful question. SuperQuestions is a different product: it represents and manages the project's questions with their evidence, their decisions, their dependencies and their work. Repositories and workflows supply code and activity. The orchestration distributes work while preserving the shared representation of the project.

Environments are configured per project: repositories, people, agents, models, tools, sandboxes, rooms, permissions and evaluation criteria.

## Agents in business operations

In ERP-Bots, agents can interpret requests, identify cases, query the ERP, retrieve documents, apply policies, prepare actions, request authority, coordinate bots and check results.

The operation rests on software, workflows and contracts. The conversation makes access easier; the orchestration sustains the work.

## Agents in knowledge and reporting

Agents can coordinate search, extraction, comparison, selection, composition, review and publication.

Finaz uses editorial roles and differentiated controls.

In knowledge systems, agents can formulate queries, expand evidence, detect contradictions and propose updates under review.

## Model routing

Different tasks may benefit from different models.

The system can choose according to difficulty, modality, language, cost, latency, context, tool use, privacy and observed quality.

Routing can use rules, learned policies or prior evaluation. The selection is recorded so that model, cost and result can be related.

## Budgets and stopping criteria

Every path can limit tokens, calls, time, cost, depth, number of tools, retries and participants.

Stopping criteria include objective satisfied, sufficient evidence, no permitted route, need for authority, budget exhausted, excessive uncertainty and unrecoverable failure.

The ability to stop is part of intelligent behaviour.

## Evaluating agents

**Result.** Whether the task or the operation reaches its completion criterion.

**Path.** Whether the tools, sources and decisions were appropriate.

**Policies.** Whether the agent respected permissions, limits and authorisations.

**State.** Whether it preserved and updated the context correctly.

**Efficiency.** Cost, latency, steps, redundancy and coordination.

**Recovery.** Behaviour in the face of failures, duplicates, late events and incomplete routes.

**Abstention.** The ability to recognise a lack of information, authority or tools.

**Human intervention.** Quality of the context and usefulness of the decision requested.

**Multi-agent.** Attribution, consistency, conflicts and the added value of the specialisation.

## Technologies and methods

The construction rests on foundation models and model routers; typed tools described with Pydantic and exposed through MCP and FastMCP; path graphs with LangGraph and PydanticAI; durable execution with Hatchet; persistence and recovery with PostgreSQL, pgvector, NATS/JetStream, APIs and events; sandboxes for the actions that need isolation; and evaluation systems, DSPy and GEPA to measure and optimise the paths.

The selection is argued from function, data, cost, latency, accountability, maturity and result, never from novelty.

## Conditions of use

Agents are especially useful when there is contextual variety and a bounded set of tools.

Rules and deterministic software keep the constraints that need reproducibility and control.

The architecture declares what each agent may propose, decide and execute. Authority is distributed by action and consequence.

Evaluation covers paths and results, adverse cases and coordination costs included.

---

https://www.3.14financialcontents.com/llms-en.txt · https://www.3.14financialcontents.com/llms-full-en.txt