What an Agentic Platform Actually Is

Your organisation has six teams building agents. Each one has its own model credentials, its own tool integrations, its own idea of what an agent is allowed to do, and no two of them can tell you what their agents did last Tuesday. That is the problem a platform exists to solve.

There is no shortage of material on building an agent. There is almost nothing on running four hundred of them against systems that move money, and those are different jobs. This course is about the second one.

An agentic platform is not a framework, not a chatbot, and not a model deployment. It is the infrastructure layer that sits between agents and everything they can reach, so that the organisation can answer one question at any moment: an agent is about to act against a real system — who is acting, on whose behalf, with what authority, under what policy, and can you prove it afterwards?

This lesson defines the object. Everything else in the course fills in a box.

The problem

Start with what those six teams actually built, because the duplication is not the interesting part.

Each team holds its own provider credentials. That is six sets of keys in four secret stores, and when one leaks you cannot enumerate which agents used it, which data passed through it, or what it cost. Each team wrote its own client for the same core system, so there are six retry behaviours and six answers to what happens when a call times out with an unknown outcome. Each team encoded "what this agent is allowed to do" in a prompt, which means the authorisation policy is a paragraph of English inside a string literal, unversioned, untested, and evaluated by a probabilistic model. And no team captured what its agents did in a form anyone else can query, so the honest answer to "what happened last Tuesday" is a grep across application logs that were never designed for the question.

Every one of those is a familiar platform problem. You have solved versions of all of them for microservices. The reason the microservices playbook does not port cleanly is worth being precise about, because it is the whole justification for this course.

With ordinary services, the code is the contract. You can read a service and know the set of things it will do. Review the code, review the IAM policy, and you have bounded its behaviour. Testing is meaningful because the same input produces the same output.

With agents, none of that holds. The agent's behaviour is decided at runtime by a model, from a prompt you did not fully write, over context retrieved from documents you do not control, using tools it may have discovered a moment ago. A code review of an agent tells you what it can reach, not what it will do. There is no input set you can enumerate, and running the same task twice can produce two different plans.

The second thing that breaks is scale in the wrong dimension. Six teams with ten tools each is not sixty integrations, it is sixty capabilities that any agent may combine in an order nobody designed. An agent with a read tool and a write tool has, in effect, a copy tool. An agent with a search tool and a send tool has an exfiltration tool. The dangerous combinations are emergent, and they emerge at runtime.

The third is attribution. When one user request fans out into an agent that delegates to another agent that calls three tools and eleven model completions, the request-scoped identity and cost tracking you already have quietly stops meaning anything. Your invoice becomes one number. Your audit trail becomes a set of disconnected spans.

How it works

A platform is easier to reason about if you start from a constraint rather than a component list.

An agent, sitting in its runtime, can only affect or learn about the world outside itself in two ways. It can call a model, or it can call a tool. That is the entire surface. Everything an agent knows that did not come from its own context came through one of those two exits, and everything an agent has ever done to a real system went out through the second one.

That constraint gives you the layers. From the user inward:

Trace one request through it. A user asks an agent to raise a credit limit. The channel authenticates the human and opens a session carrying that principal. The kernel starts a task, allocates a scratchpad, and begins a reasoning loop under a step and token budget. The loop needs context, so it queries the knowledge foundation, which filters results by what this user is allowed to see rather than what the index contains. The loop needs a completion, so it calls the model gateway, which routes to a permitted model for that data classification, records tokens against tenant, agent, and task, and returns. The model emits a tool call. That call goes to the action gateway, which resolves the composite identity — agent-01 acting for this user under a delegation scoped to this task — evaluates policy against the specific arguments, checks limits, attaches an idempotency key, executes, and writes an audit record linking the action to the reasoning trace and the policy decision that permitted it.

Five layers, two exits, one auditable chain. Every module in this course is a deeper pass over one of those boxes.

Platform design implications

The layering is not just a drawing. It implies a specific division of responsibility, and getting that division wrong is how platform teams build things nobody adopts.

The platform owns the choke points, not the logic. The platform decides which models an agent may call, which tools exist and who may see them, what identity is asserted, what gets logged, and what happens when an action exceeds a limit. It does not decide how an agent decomposes a task, what its system prompt says, or which framework the team writes it in. Those are product decisions, and a platform that takes them will be routed around.

Enforcement lives outside the agent. This is the practical consequence of the key callout above. Any control implemented as an instruction in a prompt is advisory: it works most of the time, which is the worst property a security control can have. "Never call the refund tool for more than $500" belongs in the action gateway as a rejected request, not in the prompt as a sentence the model will usually respect.

Identity is the spine, not a feature. Notice how many of the layers needed to know who the principal was. If the composite identity does not propagate from the channel all the way to the action gateway, then every downstream control degrades into "some agent did something." Module 7 is the longest module in this course for that reason.

Audit is a design input, not a log level. The regulator's question is "why did this happen, on whose authority" — which means the action record has to link to the reasoning trace and the policy decision at the moment of the action. You cannot reconstruct that later from application logs. Either the architecture captures it inline or the answer does not exist.

Tradeoffs and decision framework

Be honest about when this is overkill, because building a platform for two agents is a good way to spend a year producing nothing anyone wanted.

You probably do not need this yet if: there is one team, agents are read-only or draft-only with a human executing every real action, all traffic goes to one provider, and nobody outside the team depends on the output. Two agents behind one shared gateway with decent logging will serve you fine.

The signals that you have crossed the threshold are specific:

• A second team starts building agents, and asks you for model credentials.
• An agent is given a tool that writes to a system of record.
• Someone asks what agents cost, per team, and you cannot answer in under a day.
• An agent is asked to act on behalf of a customer rather than an employee.
• Anyone in risk, audit, or compliance asks for a list of what your agents can do.

The last two are the hard boundary. The moment an agent acts on a customer's behalf, you own a delegated-authority problem, and the moment someone asks for the list, you own a governance problem. Neither is retrofittable cheaply, because both require identity and audit to have been present at the time of the action.

On build versus buy: the gateways and the knowledge foundation have credible commercial and open-source options, and you should use them. The parts you will almost certainly build yourself are the policy model, the composite identity mapping onto your existing IAM, and the readiness process — because those encode decisions specific to your organisation that no vendor can make for you. Buy the pipes, own the policy.

The strongest sequencing argument is this: build the action gateway first, even before you have many agents. It is the only layer that is nearly impossible to add later, because adding it means finding and severing every direct path agents already have to real systems, and those paths multiply weekly.

Common mistakes

• Starting with a framework decision. Which orchestration library the teams use is the least durable choice in the architecture and the one platform teams argue about longest. Frameworks turn over in months; your identity and audit model will outlive several of them. Decide the boundaries first.
• Implementing controls as prompt instructions. Advisory by construction. Anything that must hold has to be enforced by something that is not the model.
• Letting agents hold provider credentials directly. Every capability the model gateway offers — cost attribution, residency policy, provider portability, caching — depends on the call passing through it. One team with a direct key permanently invalidates every number you report.
• Treating an agent as a stateless deployment. Agents have sessions, memory, and in-flight multi-step work. Draining one is not draining a pod, and discovering that during your first incident is expensive. Module 2.
• Building the catalogue before the boundary. A beautiful tool registry that agents can bypass is documentation, not infrastructure.
• Centralising agent logic. The fastest way to build a platform nobody uses. If teams cannot ship an agent without a platform-team ticket, they will ship it somewhere else.
• Deferring audit until a regulator asks. The records must be written at the moment of the action, linked to the reasoning and the policy decision. There is no retroactive reconstruction from logs that were not designed for it.

The thing to carry into the rest of the course: a platform is defined by its choke points, not its components. If you can name the two exits and prove neither can be bypassed, everything else is an implementation detail you can improve over time. If you cannot, no amount of tooling above them will hold.