Agentic AI and Multi-Agent Orchestration
Agents that are allowed to do less than you think, and audited for all of it
An agent is a language model that has been given tools and a loop. That is genuinely useful and it is also the point at which an AI project stops being a content problem and becomes a systems problem: identity, permissions, idempotency, retries, cost per run and who is accountable when it acts wrongly. The uncomfortable finding across the industry is that most work labelled agentic is better served by a deterministic workflow with one reasoning step inside it. We build the deterministic version by default and add autonomy only where the branching genuinely cannot be enumerated.
Also called: Multi-agent systems · AI agent orchestration · Autonomous agents · Agentic workflows · Agent governance · Model Context Protocol (MCP) integration
Choose your platform
Business outcomes
Multi-agent systems with explicit tool boundaries, their own identity, a deterministic orchestrator and a human approval step wherever money or reputation moves.
What changes for the business, and how we agree to measure it before work starts.
- A workflow that finishes, not a demo that impresses
- Deterministic orchestration owns branching, retries, timeouts and parallelism, with the model called for judgement rather than for control flow. That is the difference between something that survives a bad week and something that works in a rehearsal.Agreed measure: Completion rate and unattended failure rate for the named workflow, baselined against the current manual process before build.
- Agents that cannot exceed their remit
- Every tool an agent can call is declared, argument-validated and permission-scoped, and anything that writes to a business system is gated. The boundary is enforced at the gateway, not requested in a prompt.Agreed measure: Number of tools reachable per agent and the proportion of write actions behind an approval step, both recorded at design time.
- An identity per agent, not a shared secret
- Agents authenticate as themselves or on behalf of a named user, so an action in a log is attributable to something specific. Shared service credentials across agents make an audit trail decorative.Agreed measure: Whether every agent action in the audit log resolves to a distinct agent identity and an initiating user.
- Cost per run you can see before you scale
- Agent loops consume tokens unpredictably, and a reasoning step that retries three times costs three times as much. Cost is instrumented per run and per tool call from the first build rather than discovered on an invoice.Agreed measure: Cost per completed run at expected and worst-case iteration counts, agreed before the workflow is enabled for general use.
- Quality measured, not felt
- An evaluation set of real tasks with agreed correct outcomes runs on every change, scored end to end rather than per prompt. Published research is clear that self-reported productivity gains are unreliable.Agreed measure: Task success rate against the held-back evaluation set, trended per release with regressions blocking promotion.
- A governance position that survives an audit committee
- A written record of every agent, what it may reach, who approved it, what it is evaluated against and where a person must sign off. That record is usually what unblocks the move from pilot to production.Agreed measure: Named owner, tool inventory and approval points documented per agent, reviewed at each release.
Common client problems
What we usually hear first.
These are the sentences that start most engagements, and what we do about each one.
Our board wants an agentic strategy. Where do we even start?
With one process where the steps are known, the volume is real and a wrong answer is recoverable. We map the workflow, work out which steps genuinely need judgement, and build the deterministic version with a reasoning step where it is warranted. For most first engagements the honest recommendation is one agent with three or four tools, not a multi-agent system, because the operational burden of the second agent is larger than it looks.
We built a multi-agent prototype and it works about 60 per cent of the time.
That is the normal outcome and it is usually not a model problem. Compounding is brutal: agents chained loosely each lose a little reliability and the end-to-end rate collapses. The fix is almost always moving control flow out of the model and into a deterministic orchestrator that owns branching, retries and timeouts, then calling the model for the specific decisions it is good at. That change alone often accounts for most of the gap.
How do we stop an agent doing something expensive or irreversible?
By not giving it the capability, rather than by asking it nicely. Tools are declared explicitly with validated arguments, the permission attached to the agent identity is scoped to exactly what it needs, and anything that spends money, contacts a customer or writes to a system of record sits behind a human approval step. Where a client wants full autonomy over an irreversible action we will say no and explain why.
Is this just going to be renamed and deprecated in six months?
Parts of it will. This is the fastest-moving product area either cloud has, and during our own research for these pages we found vendor documentation contradicting itself on the status of two services. We design so the orchestration logic, tool definitions and evaluation set are yours and live in source control, with the platform's agent runtime as a replaceable component. We also tell you which capabilities are preview rather than letting you find out.
Can agents work across our Azure and AWS environments?
Increasingly yes, and the honest answer is that it adds a class of problem most organisations do not need yet. Both platforms now support open protocols for tool access and agent-to-agent interaction, and agent identity can federate across them. But cross-cloud agents mean two control planes, two cost models and a much harder answer to who was accountable. We would rather prove the pattern on one platform first.
Our data is not ready for AI, let alone agents.
Then agents are probably the wrong next investment and we will tell you that. An agent amplifies whatever it can reach: if permissions are wrong it acts on data it should not see, and if the source of truth is contested it acts confidently on the wrong number. Where the honest answer is that governance or data engineering comes first, we will scope that instead. It is smaller work for us and better sequencing for you.
Capabilities
What this domain covers.
- Agentic use-case assessment and triage
- Deterministic versus autonomous design review
- Multi-agent orchestration architecture
- Tool and function schema design
- Model Context Protocol (MCP) server design
- Agent identity and delegated authorisation
- Tool-call policy and action guardrails
- Human-in-the-loop and approval workflow design
- Agent memory and state architecture
- Evaluation harnesses for agent trajectories
- Agent observability and tracing
- Cost per run instrumentation and control
- Prompt-injection and tool-poisoning defence
- Agent inventory and governance registers
How we deliver
From assessment through to the day we are still operating it.
- 01
Assessment and advisory
The assessment exists mostly to talk you out of the expensive version. The output states which steps of a process genuinely need autonomy, which are better as deterministic code, and which should not be automated at all.
- Process decomposed step by step. Each step classified as deterministic, needs judgement, or must stay human, with the reasoning recorded so the design can be challenged later.
- Autonomy justified per step. A model is given control flow only where the branches genuinely cannot be enumerated, because every autonomous step is a reliability and cost risk.
- Blast radius assessed before tools. What the worst wrong action would cost, whether it is reversible and who would notice, decided before any tool is put within reach of a model.
- Tool inventory and permission mapping. Every system the workflow must touch, the identity it will use and the narrowest permission that still works.
- Cost modelled at worst-case iterations. Token and tool cost per run estimated at expected and pathological loop counts, since a retrying agent multiplies its own bill.
- Preview and maturity risk stated. Which platform capabilities in the design are preview rather than generally available, recorded with the date checked because this area renames fast.
- 02
Architecture and implementation
The pattern we default to is a deterministic state machine that owns the workflow, calling a reasoning step where judgement is needed. Multi-agent topologies are used where the work genuinely decomposes, not because the architecture diagram looks better.
- Deterministic orchestrator owns control flow. Branching, retries, timeouts, parallelism and human approval held in a state machine rather than in a prompt, so failures are recoverable and traceable.
- Tools declared, validated and allowlisted. An explicit schema per tool with argument validation, so a malformed or manipulated model output cannot become an arbitrary call.
- One governed gateway for tool access. Existing APIs exposed to agents through a single governed endpoint rather than credentials distributed into agent code.
- Memory scoped deliberately. Short-term conversation state separated from anything persisted across sessions, with a decision recorded about what is allowed to survive a run.
- Retrieved content treated as untrusted. Documents, web pages and tool responses can carry instructions, so retrieved text is never allowed to widen what an agent may do.
- Idempotency on every write. Business-system writes made safe to repeat, because an agent that retries will eventually retry a step that already succeeded.
- 03
Security and governance
Agents break the assumption that a request has a human behind it. Identity, authorisation and audit all need rethinking, and prompt injection stops being an embarrassment and becomes a privilege-escalation route.
- An identity per agent. Each agent authenticates as itself or on behalf of a named user, so an audit log entry resolves to something specific rather than a shared secret.
- Delegated authority, never borrowed. Where an agent acts for a user it carries that user's entitlements rather than a broad service permission that would let it exceed them.
- Action policy enforced outside the model. Tool calls intercepted and checked against policy before execution, because a guardrail expressed only in a system prompt is a suggestion.
- Injection treated as privilege escalation. Adversarial cases added to the evaluation suite, and tool allowlists enforced so a hostile document cannot talk an agent into a wider action.
- Full trajectory logged. Every model call, tool invocation, argument set and handoff captured, since a final answer alone cannot be audited or debugged.
- An agent inventory that is maintained. Who owns each agent, what it may reach and when it was last reviewed, because ungoverned agent sprawl is the predictable next problem.
- 04
Adoption and enablement
Agentic systems fail adoption in a specific way: people either trust them too much for a while and then not at all after one bad outcome. The work is calibrating that trust deliberately.
- Approval steps designed to be usable. A reviewer sees what the agent proposes, why, and the evidence behind it, because an approval nobody can meaningfully assess becomes a rubber stamp.
- Autonomy widened in stages. Start with propose-only, move to approve-then-act, and only then consider unattended action for low-consequence steps, with a decision at each gate.
- Failure behaviour taught, not hidden. Staff shown how the agent fails and what to do about it, so the first bad output is recognised rather than treated as a betrayal.
- Escalation path built before scale. A clear route to a person when the agent is uncertain, blocked or wrong, resourced before volume arrives rather than after complaints do.
- Trajectories reviewed with the process owner. Real runs walked through weekly during the pilot, which surfaces more design problems than any amount of prompt tuning.
- Measured against the baseline, not the vibe. Assessed on the agreed evaluation set and process metrics rather than user sentiment, because self-reported speed-ups are demonstrably unreliable.
- 05
Managed continuation
Agent systems degrade faster than anything else we operate. Models change underneath them, tool APIs move, and a workflow that scored well in March can quietly stop finishing in June.
- Evaluation suite run on every change. Model updates, prompt edits and tool changes all re-scored against the held-back set, with a regression blocking promotion rather than being noted.
- Trajectory sampling by a human. A sample of real runs reviewed on a cadence, because aggregate success rates hide the specific failure that will embarrass you.
- Cost per run trended. Token and tool spend per completed run tracked over time, since a model change or a new retry pattern can double cost without any code change.
- Tool and API drift monitored. Downstream schema and permission changes detected before they turn into silent failures inside an agent loop.
- Preview capability tracking. Anything in the design that is preview watched for change, since this area renames and deprecates faster than any other platform area.
- Agent register reviewed. Ownership, reachable tools and approval points revisited on a cycle, with unused agents retired rather than left with live permissions.
Questions we get asked
The things people ask before they commit.
Including the awkward ones. If the honest answer is that this is not right for you, that is the answer you will get.
What is the difference between an AI agent and a chatbot?
A chatbot answers. An agent acts: it is given tools, a goal and a loop, so it can call systems, react to the result and try again. That capability is the whole value and the whole risk, because the moment a model can write to a business system you have an authorisation, idempotency and audit problem rather than a content problem. Most of the engineering in an agent project is in those three things, not in the prompt.
Do we actually need multiple agents, or is one enough?
Usually one, and often none. Multi-agent designs are justified when the work genuinely decomposes into specialisms with different tools and different context, and they cost you a supervisor, a handoff protocol and a much harder debugging story. Reliability compounds badly across loose handoffs. Our default recommendation for a first engagement is one agent with a small number of tools inside a deterministic workflow.
How much does an agentic system cost to run?
More variably than anything else you will operate, which is the real problem rather than the absolute figure. A single run might make one model call or fifteen depending on how many times the loop retries, so cost per run has a long tail. We instrument cost per run and per tool call from the first build and model the pathological case, not just the happy path. Anyone quoting a monthly figure before seeing your workflow is guessing.
What happens when the platform renames or retires what we built on?
It will, and faster here than anywhere else. While researching these pages we found vendor documentation contradicting itself on the availability status of two agent services, and one major agent product closed to new customers mid-2026. We keep orchestration logic, tool schemas and the evaluation set in your source control so the platform runtime is a replaceable component, and we tell you upfront which parts of a design are preview.
Why not just wait until this settles down?
For unattended autonomy over consequential actions, waiting is a defensible position and we will say so. For the narrower pattern (a deterministic workflow with a reasoning step, tools declared explicitly, a person approving anything that matters) the engineering is well understood and the value is real now. The part that is genuinely unsettled is the platform naming and the governance tooling, not the underlying pattern.
Can an agent be tricked into doing something it should not?
Yes, and this is the failure mode we design hardest against. A document, web page or API response can contain text that reads as an instruction, and a model that treats retrieved content as trusted will act on it. The defence is not a better prompt: it is a declared tool allowlist, validated arguments, policy enforced outside the model, and an identity whose permissions do not allow the damaging action in the first place.
Who is accountable when an agent gets it wrong?
A named person on your side, which is why the governance record is part of the deliverable rather than documentation added afterwards. Every agent has an owner, a declared set of reachable tools, an evaluation set it must pass and explicit points where a human approves. If nobody will own a particular agent, that is a strong signal it should not be enabled, and we will raise it rather than build it.
Related industries
Where this work has the most leverage.
Professional Services
Governed enterprise search, document intelligence and secure copilots that respect matter confidentiality and conflict boundaries.
Logistics and Warehousing
Shipment and document automation, proof-of-delivery processing and exception dashboards that let a small team run a large network.
Construction and Property
Tender intelligence, addenda tracking and project reporting that keep estimators and contract administrators ahead of the documents instead of buried in them.
Manufacturing and Distribution
Demand and inventory intelligence, production analytics and supplier automation built on data your planners already trust.
Related services
What usually comes with it.
Artificial Intelligence
AI that is chosen for a reason, costed before it is built and governed once it is live.
Security and Governance
Close the ways in, know exactly who can do what, and answer an auditor or a client questionnaire from current evidence rather than memory.
Data and Analytics
Reporting your executives trust, produced once, with a modelled layer underneath it that the next AI or forecasting project can stand on.
Managed Services
Your platform keeps earning its business case after go-live, with cost, security posture, reliability and adoption reviewed on an agreed cycle rather than left to drift.
Free discovery workshop
Start with a agentic ai discovery workshop.
Bring one challenge in this area. We will map the opportunity, the readiness gaps and a recommended next step.