Agent responsibility
Interpret the goal, explore available capabilities, and propose a plausible path.
Agent vs runtime in UMA
One of the easiest ways to misunderstand Universal Microservices Architecture is to assume that once agents enter the picture, they become the real authority of the system. UMA makes the opposite claim. Agents can help discover, rank, and compose capabilities, but the runtime still decides what is valid, safe, and executable.
The short answer
In UMA, an agent is a reasoning component. It interprets a goal, looks at available capabilities, and proposes a path. The runtime is the execution authority. It validates contracts, checks constraints, enforces trust and placement rules, and decides whether the proposal is acceptable.
That distinction matters because modern systems increasingly include components that can generate plans dynamically. If those plans are treated as self-justifying, architecture turns into improvisation. UMA avoids that by keeping a hard boundary between proposing work and authorizing work.
- Agent: proposes what might work.
- Runtime: decides what is actually allowed to run.
- System: stays governed because planning and authority are not collapsed into one layer.
What an agent is for
Agents are useful when a system has many capabilities and no single fixed workflow fits every situation. They can help interpret goals, identify candidate capabilities, rank plausible options, and suggest a sequence that might satisfy the request. That is valuable because it lets the system adapt to context instead of relying only on predetermined paths.
But adaptability is not the same thing as authority. An agent is good at proposing. It is not, by itself, a stable place to define policy, trust, placement, compatibility, or approval rules. Those concerns need a layer that is more explicit and more governable than a generated plan.
What the runtime is for
The runtime exists to turn a capability model into governed execution. It knows what is available, what is compatible, what is allowed in the current environment, and what must be rejected even if a proposal looks plausible. It can also explain what happened, which matters just as much as the execution itself.
That means the runtime is the place where architectural rules stay explicit. It is where discovery becomes validation, ranking becomes selection, and a proposed workflow becomes an approved one. Without that layer, an agent can still produce output, but the system becomes harder to audit, reproduce, and trust.
Runtime responsibility
Validate contracts, enforce constraints, and decide whether the proposal can actually run.
Agent strength
Adaptability, ranking, and dynamic composition when the exact path cannot be fully hardwired in advance.
Runtime strength
Authority, repeatability, evidence, and governance across environments and capability boundaries.
If you remember one rule
A good UMA system can benefit from an agent without becoming agent-governed. That is the practical test. If the planner goes away, the runtime should still be coherent. If the runtime goes away, the planner should not be trusted to define the system alone.
That rule is important because many systems sound flexible only as long as nobody asks who is accountable for the final decision. UMA keeps that answer simple: the runtime is accountable for approval and execution, even when the proposal was generated dynamically.
Why this distinction matters more with AI
AI systems make the agent side more powerful, but they also make the boundary more important. As soon as the planning layer is model-driven, it becomes even more dangerous to let the proposal layer silently become the control layer. A strong answer is still needed to the question: who gets to say yes?
UMA’s answer is that the runtime says yes or no. The agent can suggest. The runtime can accept, reject, or replace that suggestion according to contracts, placement rules, trust boundaries, and current system conditions. That keeps the system explainable even when planning becomes more fluid.
What goes wrong when the distinction disappears
When teams blur the line between agent and runtime, failures start to look intelligent instead of architectural. A proposal is accepted because it seems reasonable, not because it was validated. A capability is invoked because it looked relevant, not because it matched the active constraints. Placement becomes accidental. Trust becomes inferred. Reproducibility collapses because nobody can clearly say which part of the system was merely suggestive and which part was authoritative.
That is one reason many “AI-native” system stories still feel thin from an architectural standpoint. They show dynamic plans, but not governed execution. UMA tries to keep that second part visible.
Discoverability strengthens that same boundary. Once proposal, validation, revision, and trace become inspectable artifacts, the system can explain not only that authority exists, but how it actually shaped the result.
How Chapter 13 makes this visible
The Chapter 13 reference experience is useful because it shows this boundary directly instead of leaving it implicit. The planner can rank capabilities. The runtime still validates the choice. If a proposed path violates the active rules, the runtime can reject it. The resulting workflow is not whatever the planner imagined; it is what the runtime approved.
That is the practical version of the architectural claim on this page. The live demo is not just an AI workflow viewer. It is a demonstration of runtime authority in the presence of dynamic planning.
That makes the page useful for two kinds of readers. One reader wants the concept: what is the difference between agent and runtime? Another reader wants proof: can I see the proposal accepted or rejected by a governed layer? Chapter 13 is the proof surface for that second question.
A useful design test
If you want to know whether your system is treating agents and runtimes clearly, ask a simple question: if the planner proposes a valid-looking but disallowed path, what enforces the rejection? If the answer is unclear, the architecture probably needs a stronger runtime story.
A second question helps too: can you explain, after execution, why one capability was approved and another was rejected? If that answer only exists inside the planner’s prompt or hidden reasoning, the system is still missing the governed layer UMA is trying to make explicit.
Frequently asked questions
Does UMA require an agent?
No. UMA does not require an agent in order to be coherent. A system can still use explicit workflows, fixed capability selection, and strong runtime governance. Agents become useful when the system needs dynamic selection or proposal behavior.
Can an agent ever be authoritative?
It can feel authoritative at the product layer, but in a governed UMA system it should still pass through runtime approval. Otherwise the system loses the architectural distinction that keeps dynamic planning from turning into hidden control.
Why not let the agent decide everything if it performs well?
Because performance and authority are different concerns. A planner may often suggest a good path, but a governed system still needs explicit validation, trust enforcement, and reproducible approval. Those are runtime responsibilities, not prompt outcomes.
If this page makes sense conceptually, the next step is to watch the live reference app. It makes the planner, runtime, and capability flow visible step by step. If you want the deeper architectural argument behind that design, the book is where that fuller model belongs.