Agentic Systems Do Not Fix Weak Service Boundaries

The phrase "agentic microservices" sounds more settled than the architecture currently deserves.

It suggests a clean new phase: first monoliths, then microservices, then agents calling services like tools. That story is tidy, but real systems rarely move in tidy stages. Most teams will not replace their backend architecture with a new agentic pattern. They will add agents, assistants, workflow automation, model calls, and tool execution on top of systems that already have all the old problems.

That is the important bit. Agentic systems do not make service design irrelevant. They make weak service design more visible.

If a service boundary is vague, an agent will not make it clearer. If permissions are coarse, an agent will inherit too much authority. If retries are unsafe, an agent can multiply the damage. If observability only tells you that an API was called, not why, by whom, and as part of which workflow, then debugging agent behaviour becomes guesswork with better logs.

The architectural question is not whether agents replace microservices. They do not. The question is whether existing services are ready to be used as tools by software that can choose the next step dynamically.

A Service is Not Automatically a Good Tool

A microservice API is usually designed for another application, another service, or a known user journey. The caller is expected to understand the domain, sequence the steps correctly, handle failures, and stay inside an agreed boundary.

An agent changes the pressure on that contract.

When model APIs talk about function calling or tool use, the model is not just producing text. It is choosing a capability to invoke. In a simple demo, that tool might fetch weather, search a knowledge base, or create a ticket. In an enterprise system, the tool might update customer data, trigger a refund workflow, publish content, amend configuration, or query a warehouse.

Those are not the same kind of action.

A refund workflow is a useful example. A normal admin UI might only expose refunds for settled payments, cap the amount at the original transaction, require a reason code, block duplicates, and ask for manager approval above a threshold. Exposing a broad issueRefund(customerId, amount) capability to an agent without those same state checks and permission boundaries is not the same system with a conversational front end. It is a different risk surface.

A service that was safe when called from a tightly controlled UI may be unsafe when exposed as a broad tool. The UI had constraints: hidden fields, validation, role checks, step order, and contextual copy. The agent sees a tool name, a description, parameters, some context, and whatever guardrails the system designer remembered to add.

Tool descriptions are therefore architectural documentation, not just developer convenience. They need to describe side effects, permission expectations, input shape, valid states, and failure cases well enough that a model can choose the right capability without being handed authority the backend cannot defend.

That means service contracts need to become more explicit about what the service does, what it does not do, who is allowed to call it, which fields are required, which actions are reversible, and which actions are high consequence. They also need to name valid before and after states, explain what error responses mean, and state whether repeated calls are safe.

This is not new architecture. It is old architecture made less forgiving.

Agentic Monoliths are Still Monoliths

One tempting response is to stop exposing many services and put agent orchestration into one big workflow layer. The agent gets a single facade. The facade hides all the messy systems behind it. The architecture diagram looks calmer.

Sometimes that is the right move. If the underlying estate is fragmented, a dedicated orchestration layer can protect users from bad sequencing and give teams a cleaner place to enforce policy.

But it can also create an agentic monolith: one central system that owns too much process knowledge, too many permissions, too much state, and too many exceptional paths. It becomes the place where every workflow rule, data workaround, approval boundary, and fallback condition ends up.

That might be better than letting an agent freestyle across twenty internal APIs. It is not automatically better architecture.

The same judgement applies to conventional service design. Martin Fowler's microservices article is still useful because the hard questions have not gone away. Can services be deployed independently? Do teams own them clearly? Are boundaries aligned with business capabilities? Does distribution add value or just operational overhead?

Agentic systems add another question: if this capability is exposed to a reasoning layer, does the service contract still make sense when the caller is not a deterministic application flow?

Orchestration and Choreography Get More Awkward

Microservice teams already argue about orchestration versus choreography.

An orchestrated workflow has a clear owner. Something decides the sequence and calls the services. A choreographed workflow spreads responsibility through events. Services react to events and the overall process emerges through the event flow.

Agents can sit uneasily in both models.

In orchestration, the agent may become the thing deciding the sequence. That can be useful for flexible work such as triage, search, drafting, classification, and support routing. It is dangerous when the workflow has strict business rules, approval gates, financial consequences, or legal implications.

In choreography, agents can become yet another event producer or consumer. That raises the usual event‑driven questions, only with less predictable intent. Which event means a suggestion was made? Which means an action was approved? Which means a human accepted the risk? Which event carries enough context for audit? How do you stop a model‑generated action from triggering a cascade that nobody owns?

Standards such as CloudEvents and the AsyncAPI specification help describe event and event‑driven API contracts. They do not decide workflow ownership for you.

The mistake is to let "agentic" become an excuse to avoid choosing an owner. A workflow still needs someone responsible for the policy, the state transitions, the audit trail, and the recovery path.

Idempotency Stops Being Nice to Have

Retries are where agentic architecture gets very ordinary very quickly.

Network calls fail. Model calls time out. Tools return partial errors. A user asks the same thing twice. The agent does not understand whether the first attempt succeeded. A queue retries the event. A support agent approves a suggested action without realising it already happened.

If the operation is read‑only, that may be irritating. If the operation sends an email, charges money, changes a permission, publishes content, creates an account, or triggers fulfilment, it matters.

The boring backend disciplines become central:

• idempotency keys
• optimistic locking
• clear conflict responses
• safe retry policies
• deduplication windows
• compensating actions
• explicit action status
• audit logs that include caller intent

This is one reason I do not buy the idea that agents make backend architecture more magical. They usually make it more administrative. You have to know exactly what happened, whether it happened once, whether it can happen again, and who accepted the consequence.

The same pattern appears in production debugging. A site that breaks after deploy is rarely fixed by staring at the final error message. You work backwards through logs, routes, data, ownership, and change history. Agentic workflows need that same forensic route.

Permissions Need to Move below the Prompt

Do not put security‑critical permission rules only in a system prompt.

Prompts can guide behaviour. They are not an access‑control model.

The OWASP GenAI Security Project's 2025 LLM risks are a useful corrective here because prompt injection, sensitive information disclosure, insecure output handling, and excessive agency all become worse when tools sit behind broad credentials. The UK's NCSC secure AI system development guidelines point in the same direction: AI systems still need secure design, development, deployment, and operation across their lifecycle. A conversational interface is not a security boundary.

If an agent can call a tool, the backend has to enforce whether that action is allowed. The service needs to know the real actor, the delegated authority, the user's role, the data boundary, the environment, and the consequence level of the action. It also needs to reject calls that are well‑formed but unauthorised.

That sounds obvious until an agent layer is built as a productivity wrapper around existing internal APIs. Internal APIs often assume trusted callers. They may have broad service credentials, weak per‑action permissions, or validation that relies on the old UI never sending an impossible request.

Agent access should be narrower than human access by default, not broader. Before exposing a write‑capable tool, I would want to know whether the agent is acting for a user, a team, or the organisation, whether the user can inspect and approve the final action, whether the tool receives a scoped token or a broad service credential, and whether row‑level or tenant‑level access is enforced below the agent layer. Destructive actions should be separated from read actions. High‑consequence actions should sit behind approval.

That connects agentic systems to the broader argument in AI will be OK if we stop treating it like magic. Autonomy has to be earned. The backend should enforce that, not merely hope the model behaves.

Observability Has to Explain Intent, Not Just Traffic

Traditional service observability often answers:

• which service was called?
• how long did it take?
• did it error?
• which trace did it belong to?

Agentic observability needs more:

• what user or system initiated the workflow?
• what goal was the agent trying to satisfy?
• which tools were available?
• which tools were selected?
• which options were rejected?
• what context was passed to the model?
• what policy or approval gate applied?
• what did the agent believe had happened?
• what action actually happened?

The OpenTelemetry trace specification gives teams useful instrumentation building blocks, but the domain model still matters. If every trace says tool.call and every log line records only a generated tool name, you do not have observability. You have decoration.

This is also where context windows become architectural, not just model trivia.

An agent cannot carry your whole organisation in its prompt. It receives a selected slice of context. If that slice omits service constraints, edge cases, prior state, user permissions, or recent failures, the decision can look reasonable and still be wrong. Retrieval, summaries, tool descriptions, and workflow state become part of the contract.

Backend teams need to decide what truth lives where. The prompt should not be the only place a business rule exists.

Serverless and Event‑Driven Systems Fit Some Agent Work, Not All of It

Serverless and event‑driven architectures can be a good fit for agentic systems. Many agent tasks are bursty, asynchronous, and naturally split into steps: classify a request, fetch context, draft an answer, ask for approval, write a record, notify a user.

That does not mean every agent workflow belongs in a pile of functions.

Serverless can make ownership and tracing harder when the workflow crosses many small units. Event‑driven systems can hide state transitions if event names are vague or consumers are poorly documented. Long‑running workflows need durable state, retries, compensation, and a way for a human to inspect where the process is stuck.

The right boundary depends on consequence.

Low‑risk enrichment tasks can often be asynchronous and loosely coupled. High‑consequence workflows need stronger orchestration, clearer status, and more explicit approval points. If the agent is handling a support note, failure may mean inconvenience. If it is changing account status or production configuration, failure means an incident.

That is why production data breaking a Next.js site is a useful adjacent lesson. Systems break where idealised assumptions meet messy real data. Agentic systems do the same, except the assumptions are often hidden inside context selection and tool descriptions.

Where Existing Microservice Thinking Still Applies

Most of the useful advice is not new.

Keep services cohesive. Give teams real ownership. Avoid distributed systems when a simpler boundary is enough. Keep contracts clear. Do not share databases casually. Monitor the system. Make failures visible. Test integrations. Design for retries. Keep security close to the data and action, not only at the edge.

Agentic systems do not weaken any of that.

For web platforms, the same discipline sits behind Next.js platform architecture: decide where state, permissions, caching, integration boundaries, and ownership live before automating around them.

What changes is the caller.

A deterministic application flow calls services in a known order. A human uses judgement, but is slow and accountable. An agent can be fast, plausible, and oddly creative. It may call a tool in a valid but surprising sequence. It may ask for too much context. It may make a safe API unsafe through repetition. It may produce convincing evidence of intent without having the organisational accountability of a person.

So the adaptation is not "redesign everything around agents". It is more specific:

• make tool‑facing contracts narrower and clearer
• expose read and write capabilities separately
• enforce permissions in the backend
• make idempotency unavoidable for side effects
• attach workflow identity to traces and logs
• separate suggestion, approval, and execution
• keep state outside the model where it needs to be durable
• make recovery paths explicit

That is not fashionable. It is necessary.

Wrapping Up

Agentic systems are not the next evolution of microservices in the grand, breathless sense. They are a new kind of caller placed on top of old architecture.

That is enough to matter.

If your services already have clear contracts, scoped permissions, strong observability, safe retries, durable workflow state, and honest ownership, agents can become useful clients of those capabilities. If your services are a set of loosely understood endpoints held together by tribal knowledge and optimistic dashboards, agents will expose that very quickly.

The architecture work is not to rename microservices as tools. It is to make capabilities safe enough, explicit enough, and observable enough that a tool‑calling system cannot accidentally turn old ambiguity into production damage.

Key Takeaways

• Agentic systems do not replace service design. They make weak service boundaries harder to hide.
• A service API is not automatically a safe tool for an agent.
• Workflow ownership still matters, whether the system is orchestrated, event‑driven, or serverless.
• Idempotency, retries, permissions, and durable state become more important when agents can repeat or sequence actions.
• Observability needs to capture intent, tool choice, approval, and execution, not just API traffic.
• Keep security and permission checks in backend systems, not only in prompts.
• The practical work is narrower contracts, clearer ownership, safer side effects, and better recovery paths.