You ask the agent to add a new field to the user object. Simple, right? The user-service ships clean. Order-service passes the field through. And then payment-service, which the agent never even opened, breaks reconciliation at 2 AM because it was written against a schema from six months ago that nobody bothered to tell anyone about.
The agent did the work it could see. That’s the thing. It missed everything else, because everything else lived in three other services it had no idea existed.
This is what every cross-service task looks like inside a microservices estate. Change one thing, ripple to four others through APIs, shared libraries, event streams, database contracts… pick your poison. The agent needs to reason at the service level before it touches a file. Most coding agents don’t. They can’t.
This piece is about the three primitives that change that.
Why file-level reasoning falls apart at service boundaries
The default for most AI coding agents is pretty simple. Load the file. Pull in a few similar ones by embedding similarity. Start editing.
That works fine when the task fits inside the files you loaded. It falls apart the moment the task depends on something living in a service the agent never touched. The agent has no way to know order-service even reads the user object. No way to know which schema version payment-service expects. No way to know there’s an event-bus topic carrying user data to god-knows-where downstream.
And retrieval doesn’t fix this. People think it does, but it doesn’t. Embedding similarity scores text chunks. It cannot tell you that the user-service is publishing events the notification-service is subscribed to.
That relationship lives in code, but it’s a structural relationship. A text index sees the publisher and the subscriber as two unrelated chunks. A graph sees them as connected nodes. Big difference.
The broader version of this failure pattern, including the architectural drift that builds up over hundreds of edits nobody catches, is over in Why AI Coding Tools Break Architecture in Large Codebases.
For the cross-service piece specifically, the agent needs three primitives. All of them sit on top of a service-level dependency graph.
Primitive 1: The service dependency graph
A service dependency graph maps which services call which. Every flavor of cross-service communication you’ve got. REST, gRPC, database connections, message queues.
Each service is a node. Each interaction between services is a typed edge. That’s the whole model.
How the graph actually gets built
Three detection mechanisms, running in parallel.
The first is static analysis of client SDK imports. If service A imports service B’s client SDK, that’s an outbound call from A to B. Catches direct API calls.
The second is parsing OpenAPI specs and gRPC IDL files. These declare the surface of each service. What endpoints exist, what fields they accept, which version is live. Honestly, this is the one that surprises people. Most teams have these files lying around already, so the agent gets a ton of free signal here.
The third is parsing config files. Database connection strings, message queue topic names, event bus subscriptions… all of that lives in values.yaml, terraform modules, k8s manifests. These show the shared resources that link services through state rather than through direct calls. Easy to miss without explicit parsing.
Stack those three together and you get a typed, directional model of the estate.
What the agent can actually do with it
The agent can query it now. Real questions like “which services consume the user-service API,” or “what’s the upstream chain producing this event,” or “which services share access to the payments database.”
What changes in the agent’s behaviour is honestly pretty obvious once you see it.
Without the graph, the agent reads the file you told it to edit and proposes a change. With the graph, it first checks which services are downstream, then evaluates the change against the actual surface it touches.
So take that task from earlier. Adding a new required field to the user-service API. Without the graph, the agent edits user-service, opens a PR, done. With the graph, the agent figures out four services call user-service, notices two of them aren’t sending the new field yet, and proposes a coordinated change across all five before writing a single line.
That’s primitive one. The other two build on it.
Primitive 2: Call-chain analysis
If the dependency graph tells the agent what’s connected, call-chain analysis tells it how a specific request actually flows through what’s connected.
A call chain follows an outbound call from its source to every downstream consumer. Service A handles an HTTP request, calls service B, which calls service C, which writes to the payments database. The chain is A → B → C → payments_db. Four hops, one reasoning surface, the agent sees the whole thing at once.
This matters for two things, mostly.
Debugging
A timeout in service C surfaces as a 500 in service A. The agent without call-chain analysis burns its tool calls reading service A files looking for a bug that’s actually living two services downstream. Frustrating to watch, even more frustrating when it’s happening to you on a Friday afternoon.
Planning
Cross-service changes have to be planned at the call-chain level, not the file level. Edit service A but not B, and the contract breaks at the boundary. Edit both but don’t coordinate the deploy, and the system goes briefly inconsistent in production… which is sometimes fine and sometimes a Sev 1, depending on what the inconsistency touches.
This is why coding agents that try to plan across real codebases often just fall over. There’s a good breakdown in Why Claude Code Plan Mode Falls Apart on Real Codebases if you want the long version. The plan looks fine at the file level. It misses deploy ordering, contract versioning, rollback path… none of which live in any individual file.
With call-chain analysis, the agent can produce a plan that actually names every service involved, the order changes ship in, and where to roll back from if a single deploy fails.
Primitive 3: Change-impact propagation
The third one is where it gets interesting.
Change-impact propagation walks the dependency graph from a proposed change outward, and surfaces every entity that change touches. The mechanics are pretty direct. The agent finds the change node, traverses outbound dependency edges, and treats every consumer it reaches as a follow-up question.
Does this break under the proposed change? Does it need a coordinated update? Is it safe to ship this first and update the consumer later?
The abstract version doesn’t really land, so… three examples.
Function signature change
Service A exposes getUser(id). The agent wants to change it to getUser(id, options). Change-impact propagation walks from the function to every call site. Three call sites still passing just the id? Those three are required follow-ups. The PR plan now spans the original change plus three call-site updates.
API contract change
Service A exposes a REST endpoint returning a user object. The agent wants to rename email_address to primary_email. Walk from the endpoint to every consumer service. Each consumer reading email_address is a coordinated change. The agent surfaces the full list before writing any code, which is the point.
Database schema change
Service A owns a table that the payments service reads through a shared read replica. The agent proposes dropping a column. Walk from the column to every query that reads it. If the payments service has a query selecting that column, the change gets flagged unsafe before it ships. Saved a Sev 1 right there.
Without change-impact propagation, the agent works in this structurally degraded mode where it sees the immediate change clearly and discovers consumer impact at deploy time. Staging if you’re lucky, production if you’re not.
Monorepo or polyrepo: The indexing has to span everything
Here’s the catch though. The three primitives only work if the indexing covers the full estate. And this is where most coding agents fall down.
Polyrepo
Each service lives in its own repo. The dependency between service A and service B is a Git commit in one repo referencing a contract declared in another.
If you’re indexing one repo at a time, you literally cannot see the dependency. It exists between the repos, not inside any one of them.
Monorepo
Doesn’t actually solve this either. Sure, every service lives under the same root, but the agent’s working context still can’t hold the full thing.
Even if the codebase is technically indexed end-to-end, the agent only retrieves the slices it considers relevant to the immediate query. Cross-service relationships have to be modelled explicitly in the graph, not just inferred from file co-location.
So either way
Both setups need cross-cutting queries that span the full estate. “Find every service that imports the user-service SDK” needs to return the right answer regardless of whether your services share a root or live in separate repos.
This is why indexing breadth alone doesn’t fix the cross-service problem. A coding agent that indexes every file in the estate but doesn’t model the relationships between them is still missing cross-service impact, which Why Coding Agents Get Lost in Your Codebase Even After Indexing Everything gets into in detail. The fix is structural indexing, not just more files.
The three primitives need a graph that spans the full estate. Anything less and you’ve got blind spots that show up as production incidents.
What this looks like in production
Kredivo cut cross-service technical design time from 2 weeks to 4 hours using exactly these three primitives.
Their old process had senior engineers manually identifying every service in a proposed change, walking the call chains across a bunch of meetings, then coordinating the implementation plan across services.
The graph collapsed all of that into one working session. The agent identified affected services from the dependency graph, traced call chains, proposed a coordinated plan with deploy ordering and rollback points.
And honestly, the reduction didn’t come from the agent being smarter. It came from the agent finally having access to the surface the senior engineers had been reconstructing manually in every single design meeting.
What you actually see when the primitives are in place
A coding agent running with all three primitives behaves differently from the start of a cross-service task.
It opens by naming the services involved, not the files. It traces dependencies before editing anything. It proposes a service-by-service implementation plan with the change ordering specified. It accounts for downstream consumers you might not have thought about. It surfaces impact analysis up front, not as a footnote at the bottom of the response.
The difference shows up in the first few minutes. An agent operating at the file layer asks you which services are involved. An agent with the three primitives tells you which services are involved, traces the chains, and lays out the change-impact surface before writing any code. That’s the test, basically.
The broader category of architectural reasoning behind this, including the four signal classes feeding the graph and how the code graph itself works, is in How AI Coding Agents Understand Software Architecture.
