Always-on agents run production without the on-call tax

What happens to production when writing code becomes much faster? Justin Smith approaches that question from the operational side: he introduces himself as a founding product engineer at Resolve AI, with more than fifteen years in monitoring and observability, including work as an architect on Splunk’s Observability Suite and a tenure at VMware. His interest in product design and front-end architecture also shapes the question of where engineers should interact with operational agents.

AI-assisted development produces larger pull requests and more frequent releases. It also lets people ship code without necessarily understanding its operating principles. That increases development output, but it leaves the downstream work intact. Smith cites an unnamed survey putting 70% of engineering time outside writing code, which he describes as running shipped software. The survey’s population and methodology are not supplied.

That work includes maintaining platforms, scaling infrastructure, debugging incidents, serving on call and shipping hotfixes. It also includes handling alerts, updating runbooks, restoring services, managing escalations and answering other teams’ questions. Faster code generation does not remove these responsibilities; it can increase the number of changes engineers must understand.

Smith also describes tightening token allowances, rising prices and stricter company controls on AI use. These are his observations, rather than a comparison of named providers or plans. Together, they motivate a broader requirement: production AI needs domain context around the model, so that model capability translates into useful work inside a particular environment.

Production systems were already complex before AI accelerated development. Multiple teams operate interdependent systems, pursuing local goals that must stay aligned with organizational goals. Resolve’s founding hypothesis is that increased coding velocity will create more production issues, making AI assistance valuable on the operational side as well. Smith says work with engineering customers operating at large scale informs that hypothesis; it is not a demonstration that on-call work has disappeared.

Resolve’s agents began with on-call work: triaging incoming alerts and investigating root causes. An engineer returning to an on-call rotation after several weeks may not know the latest changes or every system involved. An agent can help assemble that missing context. When a single page expands into a cross-team incident, the coordination problem grows too: responders need a shared account of where the incident is happening and what it affects.

Background agents address what remains when there is no active fire: context handoffs, one-off issues and the nagging question of whether a subsystem is healthy. Smith describes an architecture combining models, context, reasoning and actions. Its difficult requirement is an evolving knowledge system. More capable models do not automatically know how a company’s services interact, where its hotspots are or which causal chains matter. That understanding must be captured and kept current as the environment changes.

An enterprise layer sits beneath that architecture, though Smith does not detail it here. The rest of the talk narrows to background agents rather than immediate incident response.

Asked about agents outside coding, audience members suggest meeting reviews, market research and therapy. Smith connects meeting reviews to Granola, which had appeared during the presentation. These are audience examples of non-coding workflows, not demonstrated Resolve capabilities. They lead into a less conspicuous category of engineering work: responsibilities that lack the clear starting signal of a page or incident bridge.

Someone still has to watch a deployment finish, prepare a morning incident digest and investigate recurring P99 latency drift that has not crossed an alert threshold. Someone must produce a capacity report against a quarterly goal and check system health before a customer complains. These tasks consume attention even when nothing explicitly announces that they are due.

Smith defines a task as execution plus the context needed to execute it well. Tool access can get an agent to a dashboard. Production context lets it recognize that a metric looks wrong and decide to investigate another layer.

The distinction is between obtaining a value and understanding its significance. A useful background agent needs both.

Three questions define the background-agent machinery: when does it work, how does it run and how does it know what to do? The activation mechanisms are simple enough to compose into many workflows.

Smith’s team hands over on-call duties on Thursdays. A scheduled agent can prepare the preceding week’s important trends for the next engineer. Event-driven work instead begins when a connected system emits something worth acting on, such as a CI/CD deployment or a Slack message.

Execution lives in the cloud, so closing a laptop does not stop the agent. Smith describes a sandbox with a filesystem that lets the agent organize its work. Beneath individual runs, a memory and learning system supports reflection: what a task discovers can improve its next run, and shared knowledge can carry lessons into other tasks.

A task system supplies the work definition, imports existing skills and connects the necessary integrations. These primitives are intended to support more than a fixed catalog. The four workloads that follow are examples Smith says have worked inside Resolve and with customers.

Deployment monitoring starts with the observation that every change creates an opportunity for something to go wrong. Existing CI/CD checks provide useful baselines, but they are not exhaustive: different releases need different signals. Feature flags and infrastructure changes may also happen outside the monitored pipeline, leaving the on-caller to reconstruct who changed what only after an alert fires. A background agent can watch those change events and assess system stability.

Scheduled health and anomaly checks inspect systems without waiting for an alert. A morning dashboard review might look for unusual behavior overnight. A task can also be temporary: after changing an integration, ask an agent to watch the third-party service for a week, then stop. Operational reports and handoffs turn those observations and other operational activity into information teammates can use.

First response to engineering questions targets interruptions. Smith describes watching Slack channels while trying to build software: the questions may be easy to answer, but responding breaks concentration, while not responding leaves colleagues waiting. Internally, Resolve’s agent already has access to much of the information people ask about. It watches critical channels and decides whether it has enough confidence to answer. If uncertain, it can DM an engineer for confirmation before posting a response.

The deployment demonstration takes place in an explicitly fake application environment and a demo Slack workspace. Posting a GitHub tag gives the agent a potential release event. It first identifies that event as a release, then inspects the changes to choose telemetry that could reveal whether the system has entered an abnormal state. The result is a monitoring plan specific to that release.

The agent complements the CI/CD pipeline. It adds the change-specific attention that would otherwise require an engineer to watch each release closely. In the example involving checkout and the currency service, Smith points to checkout latency, error rates and the Kafka pipeline as signals to inspect along the relevant causal chain. The useful mechanism is the connection from the change to its possible effects, rather than a fixed list of checks applied to every release.

Monitoring can continue beyond one pass. Smith contrasts a hard-coded fifteen-minute recheck with user-guided autonomy: an agent might wait another hour because a problem is intermittent, or revisit the deployment after three days to assess whether it remains healthy and produced the expected effect. These are possible follow-up decisions, not elapsed runs shown in the demonstration. The same approach can attach to feature flags, infrastructure changes and other event sources.

The next Slack example is an on-call handoff report summarizing the preceding day. It contains investigation summaries, notable changes, completed work and critical open items. This gives the incoming engineer a shared starting point, but the displayed report is verbose.

Smith replies in the report’s thread to ask for a shorter version. The intended operation goes beyond editing the current answer: the agent updates the underlying task so future scheduled reports are less verbose. He says this works, but moves on before the update completes. The visible result is the submitted feedback, not a revised report.

The channel-watching demonstration removes the need to invoke Resolve explicitly. A user can post a problem without an @mention, or even without knowing the agent exists. The configured watcher responds when it believes it can help and otherwise stays silent. Smith shows a message for which it has chosen not to respond. Selective participation matters here: watching a channel does not mean answering every message.

A separate UI exposes tasks, reports, previous runs and the underlying work performed to accomplish a task. That inspection surface provides visibility, while Slack—or Microsoft Teams—is intended to remain the everyday interaction surface. Engineers can inspect the agent’s work without moving every operational conversation into another product.

Creating a recurring health summary follows the same conversational approach:

1. Ask the agent for a recurring health summary for the team.
2. Let it explore the connected environment and ask clarifying questions about content, report type and verbosity.
3. Test the initial task before sharing it with the rest of the team.

The task definition emerges from the environment and the user’s requirements, rather than requiring the user to specify every integration step up front.

The best work to delegate depends on the company. Its service relationships, operational needs and accumulated knowledge determine where an agent can save the most attention. That is why Smith returns to the knowledge system: understanding the particular environment makes it possible to select useful work, rather than merely automate a generic checklist.

For teams building their own agent harnesses, Smith says the capabilities shown can be accessed through MCP servers, bringing Resolve’s production context, operational work and learning into another system. Current Resolve MCP documentation uses /mcp/v2 and documents chat and investigation tools; it does not establish exhaustive access to every task operation shown in the recording. Existing skills can come along too, avoiding duplicated workflow definitions.

The expensive part of operational work is understanding a changing environment, as well as executing the task. Scheduled and triggered agents make that work composable. Resolve remains a place to inspect findings, while routine interaction can stay in the tools where the team already works. The intended shift is from repeatedly assembling context by hand to giving persistent agents enough context to carry useful work forward.