Agentic AI that does the work
Agentic AI is software that pursues a goal across several steps: it decides what to do next, calls real tools to do it, checks the result, and stops to ask a person when the next action cannot be undone. The difference from a chatbot is not intelligence. It is that something happens afterwards.
37
agents in production across four systems
7
frameworks we ship on, chosen per problem
0
irreversible actions taken without a person
What agentic AI is, in two distinctions
What separates an agent from an assistant
An assistant returns text and the work starts when you read it. An agent holds the process: it plans a sequence, calls tools, reacts to what comes back, and carries the task to a result. The test is simple — if the system produced nothing but words, it was an assistant.
What separates a demo from a system
A demo runs the happy path once. A system runs the same workflow ten thousand times, on real data, while models time out, tools return half an answer and two agents reach opposite conclusions. Everything below this line is about the second one.
Thirty-seven agents, five systems
Four of these are our own products, which is why we can open them up rather than describe them. The fifth is a delivered client system, described by role only — we name no client, and nothing of theirs.
23
Paralegent AI
Our contract-review product: twelve scoring agents, one per legal category, smart-routing to eleven specialist analysts. Circuit breakers, two-tier retry, tracing on every request, and model-agnostic by design.
7
A family-office platform
A supervisor-router dispatching to financial, legal, knowledge, document, calendar and email specialists, with 62 tool functions and 105 endpoints behind them.
4
VectorHire
Resume, professional-network, code-host and live voice-interview agents screening a candidate at the same time rather than in sequence.
3
An AgentCore reference build
Advisor, budget planner and compliance guardrails on AWS Bedrock AgentCore — guardrails written in code that block non-compliant requests as they happen, with persistent memory.
1
A manufacturer, delivered
A multi-agent decision assistant over the ERP — natural language to SQL, to API, document retrieval and OCR — delivered inside the chat tool the executives already used.
Where agentic systems break
Every one of these is a failure we have had to engineer around, and every one has a full article behind it. This is what the second month of running an agentic system looks like.
It should have been one agent
Splitting a task across specialists adds coordination cost to every request. If one model with good tools can do the job, several models will do it slower and for more money.
Read the full piece →Nobody can tell which agent broke
A single trace per request is enough for one agent and useless for nine. Without per-agent spans, a wrong answer is a black box and the only debugging tool is re-running it.
Read the full piece →The retry sent the email twice
Retries are correct for reads and dangerous for writes. An agent that retries a side effect without an idempotency key performs it again, and the second one is indistinguishable from the first.
Read the full piece →The same context is paid for fourteen times
Every agent that receives the full history pays for the full history. Cost grows with the product of agents and turns, not the sum, and it only becomes visible once real volume arrives.
Read the full piece →There are no brakes
Agents that hand work to each other need a stated stopping condition. Without one, a disagreement becomes a loop that runs until a budget or a timeout ends it.
Read the full piece →One poisoned agent poisons the chain
Text from one agent is instruction-shaped input to the next. Where a trust boundary is not drawn between them, a single compromised step reaches every step downstream.
Read the full piece →The agents do not share a brain
They pass notes. What survives a handoff is exactly what one agent chose to write down, and most context loss happens at that seam rather than inside any agent.
Read the full piece →It was built as a line when the work was a graph
Steps arranged in sequence wait on each other for no reason. Work that has no dependency between its branches should run at the same time, and latency is usually shape, not model speed.
Read the full piece →The agent keeps forgetting
A longer context window postpones the problem rather than solving it. What an agent should carry forward is a decision about relevance, and that decision has to be designed.
Read the full piece →It reported success when the write failed
An agent reads the response it was given, not the state of the system. Where the tool returns an acknowledgement rather than a confirmation, the agent will report work that never landed.
Read the full piece →Six patterns we have proven in production
Anyone can wire a model to a tool. What decides whether it survives contact with real traffic is where the guarantees live.
Supervisor and router orchestration
One agent that decides, specialists that do. The alternative — every agent seeing every request — is simpler to build and far more expensive to run.
Typed tool contracts
A tool is a schema, not a prompt. If the model cannot produce a valid call, the call does not happen.
Guardrails in code, not prompts
A prompt asking a model to behave is a request. A policy engine that refuses the action is a guarantee. Dispensable actions go through the second one.
Human in the loop at the boundary
The system proposes and a person disposes, wherever the action is irreversible. That boundary is designed in, not bolted on after a bad week.
A judge before delivery
Output scored against a rubric before it ships — in one build, every lesson is scored before a teacher ever sees it.
Deterministic overrides
Where arithmetic beats judgement, arithmetic wins. A real design rule from one of our systems: an ordinal is arithmetic, a name is judgement.
Route first, then reason
Smart routing cut LLM calls by 75% against the brute-force version of the same system.
Running every specialist against every input is simpler to build and far more expensive to run, and the difference only shows up once real volume arrives. That is the kind of decision this work is actually made of — not the model you pick, but what you decide to stop calling.
Chosen per problem, including none
We build custom orchestration where a framework would fight the problem — our contract-review pipeline has no framework dependency at all, and that was the right call for it.
Agent orchestration in production
The infrastructure layer: memory, authorisation, scaling, observability — everything between a demo and a system.
See the system →Deploying on AWS Bedrock AgentCore
Typed action groups, guardrails tuned per group, memory with a schema, and three environments as code — inside your own account.
See the deployment →Agentic AI inside the system that runs the business
Most agentic AI writing stops at the demo because the author has never had to put one next to a general ledger. We build these inside Microsoft Dynamics 365, SAP and modern ERP platforms, which is where the interesting constraint lives: an agent can read widely, it writes back only what it created, and anything that moves money or stock is prepared for a person to approve rather than executed.
That boundary is a design decision, and it is stronger than promising autonomy.
What agentic ERP means in practice
The category page: what an agent may read, what it may write, and what it must hand to a person — tiered, with the six stages of getting there.
Read it →AI across Dynamics 365 and SAP
The wider ERP AI track — where agents sit among retrieval, document intelligence and the optimization apps.
Read it →Agentic AI, answered plainly
- What is agentic AI?
- Agentic AI is software that pursues a goal over multiple steps rather than answering once. It decides the next action, calls real tools to carry it out, checks what came back, and escalates to a person where an action cannot be reversed. The distinguishing property is not the model — it is that the system holds the process.
- What is the difference between an AI agent and an agentic workflow?
- An AI agent is one actor that can choose and call tools. An agentic workflow is the process those actors run inside: the sequence, the branch conditions, the retries, the stopping rule and the approval step. Most production problems are workflow problems, not agent problems.
- When does a multi-agent system beat a single agent?
- When the sub-tasks need genuinely different tools, different context or different models, and when they can run at the same time. If one model with a good tool set can do the job, several will do it slower and cost more, because every handoff adds coordination and repeats context.
- How do you stop an agent taking an action you did not intend?
- Not with a prompt. A prompt asking a model to behave is a request; a policy engine that refuses the call is a guarantee. The pattern we ship is typed tool contracts, an authorisation check in code before any side effect, and a human approval step on anything irreversible.
- How do you evaluate an agentic system?
- End-to-end success rate is necessary and not sufficient, because it tells you a run failed without telling you where. Useful evaluation scores each step against a rubric, traces per agent so a failure can be attributed, and judges output before delivery rather than after a user has seen it.
- What does agentic AI cost to run?
- The model bill is driven by how much context is repeated, not by how clever the prompt is. Every agent receiving the full history pays for the full history, so cost scales with agents multiplied by turns. Routing so that only the relevant specialists are called is usually the single largest saving available.
- Which framework should an agentic system use?
- Whichever one the problem argues for, including none. We ship on LangGraph, LangChain, CrewAI, Google ADK, AWS Bedrock AgentCore, AutoGen and MCP, and our own contract-review pipeline has no framework dependency at all because a framework would have fought that problem.
- Can agentic AI run inside an ERP like Dynamics 365?
- Yes, with a boundary. An agent can read widely across Dynamics 365 or SAP, it writes back only records it created itself, and anything that moves money or stock is prepared and proposed for a person to approve. That constraint is what makes the system safe to leave running.
42 articles, in the order they are useful
Written while building the systems above, which is why the failure modes are specific. Start wherever your problem already is.
Decide the shape
Before any of it is built
Where it breaks
The nine failure modes, each one published in full
- Your multi-agent system is a black box
- When a multi-agent system fails, which agent broke?
- Your retry just sent the email twice
- You pay for the same context fourteen times
- Your multi-agent system has no brakes
- One poisoned agent poisons the chain
- Your agents don't share a brain. They pass notes.
- You built a line when the work was a graph
- There is no such thing as a local change
What the agent carries forward
Memory, and why a bigger context window is not the answer
Running it in production
Evals, judges, retries, queues and partial failure
- The production LLMOps stack: evals, judges, retries, circuit breakers
- LLM-as-judge with temperature-escalation retry inside a 60-second budget
- Smart category-score routing that cuts LLM cost
- Bias-detection alerts on a four-agent candidate evaluation pipeline
- Surviving partial failure in a 3,300-call agent pipeline
- When to mix SQS FIFO and standard queues in an agent pipeline
Inside the ERP
What changes when the agent sits next to a general ledger
- What can't Copilot do in Dynamics 365, and what do you build instead?
- Are Dynamics 365 ERP form tools just RPA with a new name?
- Can an AI agent in Dynamics 365 give itself more permissions?
- Why is my ERP agent answering with yesterday numbers?
- Why did my ERP agent report success when the write actually failed?
- What does a Dynamics 365 ERP agent actually cost to run?
- Do I need a Dynamics 365 licence for an AI agent's identity?
- Why can't I see my ERP agent's permissions in Entra?
- How do I expose my own X++ business logic as an agent tool?
- What happens to my ERP agent on 1 October 2026?
- MCP server, virtual entities or dual-write: how should an AI agent read Dynamics data?
- In-app Copilot sidecar or a Copilot Studio MCP agent, which one?
- What can the Procurement Agent not do yet?
- Data tools, form tools or action tools: which does your ERP agent need?
- Which environments can run the Dynamics 365 ERP MCP server?
- Does the Dynamics 365 ERP MCP server truncate results?
- Which model should a Dynamics 365 ERP agent run on?
Bring the workflow you would trust an agent with
This is our AI engineering practice
It is real work and it is where our four products came from. But what Cognilium leads with is narrower: optimization apps that run in tandem with Microsoft Dynamics 365, computing the decisions the ERP records but does not derive — the optimal price, the optimal pick path, the optimal stock level. See the optimization apps · How we build inside the ERP.