How agents are built and run

Primitives

In the visual agent builder every agent is composed from eight primitives. The Autonomous Agent uses the same primitives; an agent produced by dialogue runs and is observed exactly like one designed by hand.

The supervisor → sub-agent → supervisor pattern

This is the core execution pattern of Aginies. The supervisor is not a single expert but a planner and merger; specialist agents take narrow, well-defined tasks. Control returns to the supervisor after every step, so one sub-agent’s failure does not break the whole process.

1. The supervisor receives the request and decomposes the objective into structured steps.
2. It delegates each step to the right specialist; independent steps run in parallel.
3. The sub-agent works with its own model and tools and returns the result with its rationale.
4. The supervisor verifies, merges and decides the next step.
5. Where approval is required the process pauses; the decision is recorded, then it resumes.
6. On completion the outcome goes to the channel; the full trace is written to the audit log.

Execution is stateful: steps, intermediate results and tool responses are kept. When a dependency fails the supervisor retries, switches to the fallback model or escalates to a person; the process resumes where it stopped.

Tools and MCP policies

Agents reach enterprise systems through tools: REST APIs, databases and Model Context Protocol (MCP) servers. Every tool is classified as read or write and carries its own invocation policy. The MCP Hub catalogues approved servers only.

• Read / write class: write tools are bound to an approval or threshold rule by default
• Per-tool invocation policy: allowed parameters, rate limit, which agents may call it
• Input and output masking: sensitive data to and from the tool is redacted
• Every call appears in the trace: parameters, duration, response code and result
• MCP Hub: approved servers, versions and access rights under central management
• Agent-to-agent communication (A2A) works under the same policy framework

Approvals and thresholds

Human approval is a primitive, not a control added afterwards. On a critical decision the process pauses, the decision is presented to the approver with context and rationale, and the outcome is written to the audit trail. Thresholds and approvers are set in the agent definition.

• Amount threshold: transactions above a value go to the approver
• Risk threshold: a score or guardrail signal triggers approval
• Policy exception: out-of-policy requests always reach a person
• Irreversible actions: mandatory approval for deletion, payment and contract changes
• Approver role: defined roles such as branch manager, compliance team, release manager
• Kill-switch: immediate stop and automation limit per agent or scenario

Run lifecycle

Every run is made of nine step kinds. Each agent page in the library shows its steps with these kinds; the duration, token usage and touched system of every step are recorded in the trace.

1. Ingest: the signal arrives; voice, email, API, message or event
2. Plan: the supervisor decomposes and routes
3. Retrieve: lookup in the knowledge base or database (RAG)
4. Reason: classification, extraction, scoring
5. Tool: a read call to an enterprise system or an MCP tool
6. Verify: guardrail, policy and consistency checks
7. Approval: the human-in-the-loop checkpoint
8. Write: a state-changing action in an enterprise system
9. Notify: customer or staff communication

A run starts with an ingest step and ends with a write or notify step. End-to-end latency is derived from the step durations; cost per run is computed from the token usage of model calls and attributed by scenario, unit and channel.

The agent library

The library holds 63 agents across 14 sectors. Each is a simulation derived from real agent definitions: supervisor, specialist agents, systems, steps and approval rule are all defined. Every one can be produced with the Autonomous Agent and adapted to the enterprise’s systems.

How to read an agent page:

• Title and tagline: the agent’s purpose and outcome-oriented summary
• Trigger and outcome: what starts the run and what is true when it finishes
• Channels: voice, email, app, API, WhatsApp, web or batch
• Supervisor and agents: each agent’s role, model and tools
• Systems: the core, CRM, ERP, ticketing, payments and other systems touched
• Steps: in execution order with kind, target system, duration and tokens
• Approval rule: the threshold and approver of the human checkpoint, where present
• Metrics: monthly runs, success rate, median duration, cost per run
• Inspired by: the global pattern the agent mirrors; not a customer claim

The SDLC agent team

Within Code Aginies five roles work together in the CI/CD pipeline. They own the process from request to production; code review and the production decision always stay with people. Every step is traced in Jira, Git and CI records.

• Project Manager Agent: triages requests, clarifies scope and dependencies
• Analyst Agent: writes acceptance criteria and test scenarios
• Architect Agent: produces the design and impact analysis
• Developer Agent: implements on a branch and opens the PR
• Tester Agent: generates and runs unit and integration tests, reports coverage

In the CI/CD pipeline SAST, dependency scanning and staging smoke tests run automatically. Production deployment goes to release-manager approval; for hotfixes the same gates apply on a shortened timeline.

Live example: an agent at work