Agentic Systems Change Distributed-System Design, Not Just the Interface

Microservices use functional decomposition. Agentic systems focus on decision decomposition: choices about what to do and how to proceed become part of the workflow. That shift raises questions about observability, reliability, and system design, not just how people interact with software. ¹

An InfoQ article by Mallika Rao, published October 19, 2026, describes this shift and the need for updated architectural patterns and practices. ¹ The recommendations below are analysis prompted by those themes; they are not implementation steps prescribed by the article.

What changes in agentic AI architecture when decomposition moves from functions to decisions?

The article contrasts microservices' functional decomposition with agentic systems' focus on decision decomposition. ¹ One possible consequence is that a workflow's behavior may depend on choices made during execution: which tool to use, whether to ask for more input, whether to delegate a subtask, or whether to stop. These are examples for analysis, not specific claims made by the article. For a related look at how much an agent should commit to when it cannot see the whole picture, see How Much Should an AI Agent Commit to a Plan It Cannot Fully Observe?.

Analysis: Treat consequential choices as events worth examining, not just implementation details. For example, a workflow might select an unsuitable tool even though the tool responds successfully. A service-level view alone may not reveal that the decision was the source of the problem.

This does not require replacing every service with an agent. One design approach is to retain functional boundaries where they help clarify ownership, while making agent decisions and handoffs observable and governable too.

What should agent observability trace?

The article identifies observability as one of the areas made more complex by the shift to agentic systems. ¹ A practical response would be to trace decision paths alongside request and service paths.

For a workflow, proposed fields might include:

• The incoming intent and how the agent interpreted the task.
• The selected tool, model, or delegated agent, and a reason or decision category.
• Each handoff: who initiated it, who received it, what context passed along, and what happened next.
• Policy checks, retries, outputs, and why the workflow terminated.

These are proposed fields, not a format prescribed by the source. The aim is to help an operator ask not only "which service failed?" but also "which decision led here, and what information was available when it was made?"

A handoff could be represented as an explicit event:

{
  "event": "handoff",
  "from": "triage_agent",
  "to": "case_lookup_tool",
  "decision": "retrieve_case_context",
  "context_ref": "workflow_context",
  "outcome": "completed"
}

The names and fields are illustrative. Teams can choose identifiers and context references that fit their logging and privacy requirements. The proposed goal is to capture sender, recipient, decision, relevant context, and outcome, rather than relying on a final answer to explain the path after the fact.

Consider a hypothetical support workflow in which an agent repeatedly calls a lookup service when the request actually needs clarification. A decision trace could help distinguish that possibility from a problem with the service itself. The example is illustrative, not a report of an observed incident.

Who owns a wrong decision when every service is healthy?

Analysis: Infrastructure ownership and decision ownership may overlap without being identical. For example, a platform team could own a runtime or routing layer, while another team owns task policy or a particular tool. Assigning responsibility based only on the last service in a trace could miss the component that can change the behavior behind a failure.

A proposed ownership map could cover:

• The agent's task logic and permitted decisions.
• Tools and external actions, including authorization boundaries.
• Prompts or policies that shape behavior.
• Model selection and orchestration, including any enterprise AI gateway that sits in the request path.
• Handoff contracts, including what context must be preserved.

Teams could route incidents by suspected failure class: a tool problem to the tool owner, a context-loss problem to the handoff owner, a policy problem to the policy owner, a model-output problem to the team operating that model path, and an orchestration problem to the workflow owner. This is an operational proposal, not a taxonomy specified by the article.

In an incident review, teams could ask which decision generated a request, whether the action was authorized, and who can change the relevant behavior, not only whether a service returned successfully.

How should agent reliability be defined for agentic workflows?

The article identifies reliability and system-design complexity as challenges in the shift to agentic systems. ¹

Analysis: Teams could define workflow-level outcomes alongside component-health measures. Depending on the task, proposed outcomes might include correct completion, safe refusal, a valid handoff, bounded retries, or controlled termination. These measures could distinguish simple responsiveness from whether the workflow met its intended outcome.

For a deterministic service path, teams can check whether a component returned a valid response to a request. For an agentic workflow, additional review questions could include whether the selected path was appropriate, whether the action was permitted, and whether the workflow stopped or handed off when uncertain.

There may be a trade-off between tighter constraints and flexibility, while broader autonomy may create more paths to test and inspect. Which approach is suitable depends on the consequences of a wrong action and the evidence available about the system's behavior. Errors that spread between cooperating agents are one such path; ARIA's runtime repair proposal targets that gap in multi-agent systems.

What failure paths should teams test before expanding an agent's role?

The following are proposed test scenarios for decisions and handoffs, not scenarios listed by the source:

• An ambiguous request or missing context.
• Conflicting instructions or an unavailable tool.
• An invalid output or failed downstream handoff.
• Repeated retries, or an action that should be blocked.

For each scenario, teams could specify the expected decision, permitted alternatives, stopping condition, and incident owner. Testing partial failures could help expose cases where a component responds successfully but the overall task is wrong, incomplete, or stuck in a loop.

Analysis: Treat changes to an agent's permissions, tools, or delegated work as a reason to gather failure-path evidence. Before expanding its role, teams could check whether it can stop or hand off when it cannot proceed safely, and whether an operator can reconstruct the workflow from its traces. A successful demonstration alone would not answer those questions. For a broader look at agent credentials and controls, see ServiceNow's agent controls checklist.

What agentic architecture should teams adopt first?

Analysis: Start with a bounded workflow where decisions, tools, handoffs, and side effects can be observed and attributed. Retain service boundaries where they help clarify ownership, and add explicit decision boundaries around agent behavior rather than converting every capability into an agent.

Before deployment or expansion, teams could ask:

• What decision is being delegated, and what remains deterministic or policy-controlled?
• Can an operator reconstruct consequential decisions and handoffs from the available traces?
• Which team can change or disable each consequential action?
• What should happen when context is missing, a tool is unavailable, or the agent cannot proceed safely?

These are proposed design questions, not requirements stated by the article.