Agents Need Access to the Whole Stack

Coding agents can already use the same tools we use. An agent working on an iOS app can launch Simulator, navigate to a screen, read device logs, and check its work. On the web it can open the browser, inspect network requests through CDP, and profile a slow page. It can call an API with curl, inspect the database with psql, and follow the request into logs and traces.

We have to give it that access. Repositories and terminals usually come first because they are easy to expose, while the rest of the stack stays scattered across local applications, production dashboards, and separate accounts. The agent can still write code, but it is writing with a partial view of the system.

That missing context affects the implementation. A query that works against ten thousand rows may fall apart against one hundred million. The code alone will not tell the agent how large the table is, how the data is distributed, or which indexes exist in production. It should be able to look those things up before choosing an approach. The same goes for traffic, slow dependencies, error patterns, and the analytics events other parts of the business already depend on.

Instrumentability is how easily the agent can inspect all of this. A well-instrumented stack lets it answer questions about the real system before it writes code and then check its assumptions afterward.

Follow the data through the whole stack

The interfaces already exist in many cases. curl, psql, browser tools, simulator commands, and service CLIs are enough to expose a lot of the development loop. MCP servers can connect the agent to live systems such as Sentry, New Relic, PostHog, Mixpanel, or the deployment platform without forcing it through dashboards built for people.

Say checkout completion drops after a release. PostHog can narrow the drop to the shipping step. Sentry can connect the new error to a release, and a trace can show that the address fallback is making the same slow call repeatedly. The agent can follow that path into the code, reproduce it locally, write the fix, and run checkout in a real browser to see whether the duplicate requests are gone. After a canary deploy, it can check the same production signal again.

Each system adds context to the same investigation. The agent does not need a person to copy an error out of Sentry, explain what a trace says, run a database query, and report whether the funnel recovered. It can move through the data itself and produce the kind of evidence described in AI-Generated Code Should Come With Evidence.

This also makes the first attempt better. If the agent knows the table is large, it can choose an indexed lookup from the beginning. If production traces show that a dependency is unreliable, it can avoid putting that dependency on a synchronous path. Debugging still matters, but fewer obvious assumptions have to fail before the agent reaches a good implementation.

Keep the agent in the loop after merge

I have had great success keeping agents involved after the code is merged. The report below recreates a monitoring workflow I ran in production against real usage. After a fix for empty chat replies shipped, the agent compared failure counts with their pre-deploy baselines every hour. It confirmed that empty replies had dropped 92%, but it also caught generation failures and server errors running at 3.2x and 26.7x their baselines and said they needed investigation.

That monitor kept checking for a fixed 72-hour window and then stopped. Other jobs I have run post quiet daily health summaries when nothing is wrong and alert only when a threshold is crossed. Sentry, traces, database state, and product analytics can help the agent understand a task before it starts, verify the work while it is developing, and confirm the result in production. The same access can support a later analysis or postmortem because the agent already has the timeline and the evidence.

The agent does not need all of that data loaded into its context. It needs a map of the available systems and permission to query the relevant one when a question comes up. That keeps the integration consistent with context engineering: make useful context easy to find instead of making every piece of context permanently present.

Instrumentability is a top factor

Instrumentability should now be one of the top factors in a tech stack decision, alongside product fit, performance, ecosystem quality, and the team’s experience. Look at whether the application is easy to build and run from a documented command and whether the agent can inspect the result without asking someone to click through another tool. Local data should be reproducible. Logs and traces should connect back to requests, releases, and source. Production systems should have stable APIs, CLIs, or other machine-readable interfaces.

A tool can be pleasant for a person while hiding most of its state behind a dashboard. That hidden state creates manual work every time the agent needs it. A less polished tool with a good API may lead to a much faster development loop once agents are doing a meaningful share of the work.

Teams spend a lot of time comparing models and rewriting prompts because those changes are easy to see. Connecting the agent to the browser, database, analytics, and production telemetry looks like plumbing. It often removes more work than another prompt revision because it improves every task that comes afterward. This is the same visibility bias I described in the attention trap.

Give access safely

Live access should be read-only by default. Scoped credentials can let the agent inspect database state, analytics, logs, traces, and deployment metadata without allowing it to change production. The agent can use local data, a simulator, or an isolated environment for most write operations.

How far it can go after that depends on the product. On a new product with few customers and an easy rollback path, I am comfortable letting an agent fix, test, and deploy more on its own. On a mature product with real customers and a larger blast radius, I would require approval before deployment or any risky production action. Severity helps with that decision, but so do reversibility, customer impact, sensitive data, dependencies, and the strength of the evidence.

The agent can still do most of the work in the mature system. It can detect the problem, reconstruct what happened, reproduce it, prepare the patch, test it, and write the analysis or postmortem. The person steps in near the end to make the decision.

Giving agents safe access to the whole stack is one of the best ways to unlock their productivity. They write better code when they understand the system around it, and they can handle more of the work when they can verify the result themselves.