Skip to content
Aelsha Innovations

Consulting · composable agents

Composable AI agents: small agents with clear contracts, composed into systems you can audit.

Specification

You want one workflow automated end to end, but not by a single AI system you cannot test, limit or change piece by piece, and that cannot tell you which part failed.

  • Each task handled by a small agent with one job and written limits
  • Each agent tested alone, and replaceable without disturbing the rest
  • A person approves anything that cannot be undone or leaves your business
Talk to us about your projectStart with a readiness assessment →

Tell us what you want to automate. We reply by email.

A composable AI agent does one job under a defined contract: typed inputs and outputs, an allow-list of tools, its own evaluation set and an A2A Agent Card. Aelsha Innovations designs such agents on LangGraph, Google ADK or another framework, connects them to your systems through MCP, and composes them in a deterministic graph with human approval for high-risk steps.

Technical detail: standards, methods and what we check ↓
Terms used on this page
AI agent
software that reads a request, decides what to do and acts in your systems.
A2A (Agent2Agent)
an open standard that lets agents built by different teams find and call one another.
Agent Card
a published description of an agent's skills and how to reach it.
MCP (Model Context Protocol)
the open standard that lets AI agents use your software's data and actions.
Evaluation set
a fixed collection of real examples the agent is tested against before each release.
Deterministic graph
the order of steps is fixed, ordinary code you can read and test, not decided by the AI.
Least privilege
each agent reaches only what its one job needs.

agent contract

Select a field to read what it means.

Inputs
A typed schema for what the agent accepts. A request that does not match is refused before any model is called.
Outputs
A typed schema for what it returns. Output is checked before it leaves the agent, and a failed check is an error, never a silent repair.
Tools allow-list
The only tools it may call, reached through MCP (Model Context Protocol). An unknown tool, or one whose definition has changed, is refused until someone approves it again.
Permissions
Its own identity and short-lived credentials scoped to its one job. Anything irreversible or sent outside waits for a person to approve that exact action.
Evaluation set
Its own test cases, including misuse and prompt-injection cases. They run before every release and whenever the model or a prompt changes.
Agent Card
A public description of its skills and how to authenticate, in the A2A (Agent2Agent) standard, so other agents, including other vendors’ agents, can find and call it.

One agent drawn as its contract. It calls and is called by other agents through A2A (the card badge on each link), reaches tools only through MCP (the plug), and a person approves the consequential step (gold).

What is a composable AI agent?

A composable AI agent is software with exactly one job and a written contract. The contract fixes what goes in and comes out, which tools it may call, what it may change and how it is tested. Because each agent is small, it can be evaluated alone, limited tightly and replaced without disturbing the rest.

An atomic agent, in the descriptive sense used here, is a composable agent: one job and one typed contract. We use the phrase only as a description; Aelsha Innovations has no affiliation with the open-source framework of that name.

Reusable agent designs for work most enterprises share

Each design below is a specification, not a shipped product: a written contract, a tool allow-list, guardrails and an evaluation plan. They cover work most enterprises already have, such as a ticket queue or a document inbox. In an engagement we adapt the closest design to your systems.

  • SpecificationDesigned to be A2A-ready

    Service-desk triage

    What it does
    Classifies, enriches and routes customer or IT tickets, and drafts replies for review.
    Designed for systems such as
    ServiceNow, Jira Service Management, Zendesk, Freshdesk, Zoho Desk, email or chat intake.
    Guardrails
    A person approves every customer-facing reply and every change to a ticket. It holds no refund, user-admin or credential permissions.
    Framework
    Chosen per client stack. LangGraph suits long-lived ticket threads.
  • SpecificationDesigned to be A2A-ready

    Grounded research

    What it does
    Answers from your own documents and approved sources, cites every claim, and says when it does not know.
    Designed for systems such as
    SharePoint, Google Drive, Confluence, Notion, wikis and a vector store.
    Guardrails
    Read-only. Searches run with the asking person’s access rights, and a claim without a supporting passage is rejected.
    Framework
    Chosen per client stack. LlamaIndex suits retrieval-heavy work; ADK suits teams on Vertex AI or Gemini.
  • SpecificationDesigned to be A2A-ready

    Document intake

    What it does
    Extracts invoices, KYC packs, claims and contracts into validated, typed records with a field-level audit trail.
    Designed for systems such as
    Document AI or OCR services, and ERPs such as SAP, Oracle, Microsoft Dynamics, Tally or Zoho Books.
    Guardrails
    Exceptions go to a person before any money or status moves. It cannot edit vendor master data or bank details.
    Framework
    Chosen per client stack. LangGraph suits approvals that pause for days.
  • SpecificationDesigned to be A2A-ready

    Alert triage

    What it does
    Enriches, deduplicates and ranks security alerts, and writes a short investigation summary with its evidence.
    Designed for systems such as
    SIEM, EDR and identity tools such as Microsoft Sentinel, Splunk, CrowdStrike, Entra ID or Okta.
    Guardrails
    Read-only by default. Containment, such as isolating a host, is only a proposal until a person approves it.
    Framework
    Chosen per client stack. ADK suits Google Security Operations teams.
  • SpecificationDesigned to be A2A-ready

    Data query

    What it does
    Turns a business question into read-only SQL and a plain-language summary, showing the SQL and its assumptions.
    Designed for systems such as
    Snowflake, BigQuery, Databricks, PostgreSQL, SQL Server and semantic layers.
    Guardrails
    A read-only role, one statement per query, allow-listed tables, caps on rows and time, and your row-level permissions.
    Framework
    Chosen per client stack. ADK suits BigQuery teams.

  • Also specified

    • Code review

      Reviews pull requests and posts comments with evidence. It never merges or pushes.

      SpecificationDesigned to be A2A-ready

    • CRM and sales update

      Turns call notes and emails into CRM changes that a rep approves before they are written.

      SpecificationDesigned to be A2A-ready

    • Marketing content

      Drafts on-brand content checked against claims and brand rules. Publishing is a separate, approved step.

      SpecificationDesigned to be A2A-ready

    • Internal request fulfilment

      Checks access, equipment and onboarding requests against policy, routes approvals and carries out approved steps with an audit trail.

      SpecificationDesigned to be A2A-ready

Why build with small agents instead of one large one

Small agents are easier to test, safer to run and simpler to govern. One job means a small, complete test set, one narrow set of credentials, and one clear place to put a person’s approval. The evidence below explains each point, and where small units do not help.

  • Each agent can be tested on its own

    In LangChain’s State of Agent Engineering survey (1,340 responses, fielded 18 Nov to 2 Dec 2025), 32% cite quality as a top production barrier and 52.4% report running offline evaluations on test sets. An agent with one job can have a small, complete evaluation set that runs before every release.

    Source: LangChain

  • A mistake stays small

    OWASP’s Top 10 for Agentic Applications (9 Dec 2025) introduces “Least-Agency”, advice to avoid unnecessary autonomy, and names Identity and Privilege Abuse as ASI03. One job needs one narrow set of credentials, so a confused or compromised agent can reach very little.

    Source: OWASP

  • Governance has somewhere to attach

    In a Deloitte survey of 3,235 IT and business leaders in 24 countries (article of 24 Apr 2026, citing its January 2026 report), 21% say their organisations have a mature governance model for agentic AI. Approval points, monitoring and audit trails are easier to define for one agent with one job.

    Source: Deloitte

Where small agents do not help

Google Research (28 Jan 2026) found that multi-agent coordination improves performance on parallelizable tasks but degrades it on sequential ones. So composable does not mean a crowd of agents talking to each other. It means small units inside a deterministic graph: the routing is ordinary code you can read and test, and each agent does one step. Source: Google Research

Anthropic reports that the most successful agent implementations it has seen were built with “simple, composable patterns” rather than complex frameworks (19 Dec 2024). Source: Anthropic

How MCP, A2A and agent frameworks fit together

Each layer does one job. MCP (Model Context Protocol) connects an agent to tools and data. A2A (Agent2Agent) carries calls between agents, each described by an Agent Card. An agent framework holds the logic inside each agent and the graph that composes them: LangGraph, Google’s Agent Development Kit (ADK), the OpenAI Agents SDK, the Claude Agent SDK, Microsoft Agent Framework, CrewAI, LlamaIndex or Strands Agents. We choose the framework per agent and per client stack; the protocols above and below it stay the same.

Diagram: agents call one another through A2A (top), each runs its own logic in an agent framework (the nodes), and each reaches your systems only through MCP (bottom).

LayerWhat it carries, and how our designs use it
Agents: A2A

Carries: Calls between agents, including agents from other vendors.

In our designs: Each agent is designed to publish an Agent Card describing its skills and how to authenticate.

Reference (verified 26 Oct 2026): A2A 1.0, the first stable specification, released 12 Mar 2026. Source: A2A spec

Logic: an agent framework

Carries: The steps inside an agent, and the graph that composes agents.

In our designs: Routing is deterministic, and an approval point pauses the run durably until a person decides.

Reference (verified 26 Oct 2026): Chosen per agent and per client stack.

Tools: MCP

Carries: An agent’s access to tools and data in your systems.

In our designs: Each agent binds only the tools on its allow-list, and stops if a tool’s definition changes.

Reference (verified 26 Oct 2026): The current MCP version is 2026-07-28. Source: MCP versioning

How an engagement runs

Four steps, each ending in something you keep. We map the workflow first and mark where a person must decide, then write a contract for each agent before any code. Build and evaluation follow, agent by agent, and the system then runs with tracing and approval gates.

  1. 01

    Map

    We trace the workflow with your team and mark every point where a person must decide.

  2. 02

    Specify

    Each agent gets a contract: inputs, outputs, tools, permissions and an evaluation set.

  3. 03

    Build and evaluate

    We build on the agent framework that fits your stack and test each agent alone, then as a system.

  4. 04

    Operate

    Agents run with tracing, approval gates and versioned releases, and we improve them from real results.

Questions about composable agents

Short answers to what teams ask first: whether the agents exist today, how they relate to the frameworks you may already use, where people approve decisions, and which models they run on. For anything not covered here, ask us directly through the contact page.

Can we buy these agents today?

Not as finished products. Each one is a specification today: a contract, a tool allow-list, guardrails and an evaluation plan. In an engagement we adapt the closest specification to your systems, then build and evaluate it with you.

Why not one large agent that does everything?

A large agent needs broad permissions, is hard to test completely and is hard to change without side effects. Small agents in a deterministic graph keep each permission narrow and each test set complete, and one can be replaced while the others stay as they are.

Do we have to standardise on one agent framework?

No. We choose per agent. LangGraph suits agents that wait days for an approval or keep long-lived threads; Google ADK suits teams already on Google Cloud, such as Vertex AI, Gemini or BigQuery. The OpenAI Agents SDK, the Claude Agent SDK, Microsoft Agent Framework and Strands Agents suit teams already building with OpenAI, Anthropic, Microsoft or AWS. Because agents meet over A2A and reach tools through MCP, an agent built with one framework can call one built with another, where both support A2A.

Where do people approve decisions?

At named points in the graph, chosen when we map the workflow. The approver sees the exact action, such as the message, the amount or the change, with the evidence behind it, not only the agent’s summary. Approvals expire if nobody decides.

Which language models do the agents use?

Yours to choose. The model is configuration for each deployment, and any change of model or prompt re-runs the agent’s evaluation set before release.

Can the agents run inside our own cloud?

Yes. The designs assume deployment in your own cloud account by default for anything that touches identity, finance, security or source code.

Start with one workflow

Tell us which workflow you want to automate. We will help you decide which small agents it needs, where a person must approve, and whether it is worth building at all.

Talk to us about your project