AI coding tools increase the amount of change entering production, while engineers still spend much of their time operating and maintaining software.
2
Background agents can run from schedules, event streams, or messages, using cloud sandboxes and shared system knowledge to perform ongoing operational work.
3
The hard part of production automation is understanding whether a signal matters in a changing environment, rather than executing a dashboard check or predefined procedure.
Summary
Justin Smith argues that coding agents have increased the flow of changes into production without removing the operational work around those changes. Engineers still spend time maintaining platforms, debugging incidents, handling alerts, updating runbooks, and answering questions. Resolve AI's background agents are intended to cover work that has no obvious page or ceremony, such as watching deployments, checking system health, preparing handoffs, and answering engineering questions in Slack. Smith distinguishes execution from production context. An agent can load a dashboard, but it needs knowledge of the environment to decide that a metric looks wrong and trace the problem further. In his deployment example, the agent reads the release changes, chooses telemetry for that release, follows the affected Kafka pipeline, and decides when to check again. Smith is careful to position this alongside existing CI/CD checks, especially for feature flags and infrastructure changes that often receive little monitoring.
Coding agents increase the operational load around production
Smith says the first wave of AI changed how software is built, with larger pull requests and code shipping more often. A survey he cites found that 70% of an engineer's time is spent running shipped code rather than writing it. That work includes maintaining platforms, scaling infrastructure, debugging incidents, taking on-call shifts, shipping hot fixes, handling alerts, updating runbooks, restoring services, and answering other teams' questions. He argues that coding was never the largest bottleneck. As AI increases coding velocity, teams need more help operating the systems that receive those changes.
Production work includes a long tail with no page or ceremony
Background agents target operational work that continues when there is no active incident. Smith lists watching deployments, producing morning reports and incident digests, checking whether a P99 drift has returned, preparing capacity reports, and running recurring health checks. These tasks often have no obvious trigger in a job description. They still matter because teams need to know whether a system remains healthy before a customer complains. The distinction is between work with a formal handoff, such as an on-call page or incident bridge, and the quieter responsibilities that engineers carry in the background.
Production context matters more than the ability to execute a check
Smith defines a task as execution plus the context needed to understand how to execute it. An agent may have access to tools and know how to load a dashboard, but that does not tell it whether a metric is abnormal. His example is a metric that simply 'smells off', even when the engineer cannot immediately explain why. The agent needs knowledge of service interactions, hotspots, current system state, and causal chains so it can decide whether a result matters and which deeper investigation to perform.
A shared learning system must keep up with changing services
Smith says models have become highly capable, but a model still needs an understanding of the environment where it works. Resolve focuses on capturing how services interact, where the hotspots are, and which causal chains deserve attention. That knowledge has to grow as the system changes. He describes a shared knowledge and memory system that can reflect on completed tasks, apply what it learned to later work, and update its understanding of the current environment. The challenge is maintaining that context while systems evolve quickly.
Background agents can start from schedules, events, or direct messages
Resolve's background agents can run on a schedule, such as a recurring report or a weekly on-call handoff. They can also react to event streams, including deployments and Slack messages, or start when an engineer sends a direct instruction. The agents run in the cloud inside a sandbox with their own file system, so closing a laptop does not stop the work. A task system, connected skills, integrations, and shared knowledge provide the instructions and access needed to complete the task.
Release monitoring can adapt checks to the change being shipped
In Smith's demo, posting a GitHub release tag in Slack causes an agent to recognize a release and decide to watch it. The agent reads the changes, chooses telemetry that can show whether those changes caused an abnormal state, and creates a monitoring plan for that release. When checkout replaces the currency service, it watches checkout latency and error rates, then follows the related Kafka pipeline. Smith says this supplements ordinary CI/CD checks rather than replacing them, especially because feature flags and infrastructure changes may bypass CI/CD and receive no monitoring.
The agent can choose how long to observe a deployment
The release checks are not fixed to a single delay such as waiting 15 minutes and stopping. Smith says the agent can decide that a possible failure needs another hour of observation because it appears intermittently. It can also return three days later to ask whether the deployment remains healthy and whether the expected effect of the change is visible. The agent's autonomy can be guided by the team. The same approach can apply to feature flags, infrastructure changes, and other event sources.
Slack can be the agent's working surface and approval channel
Smith describes an agent that watches critical Slack channels without needing to be mentioned. It decides whether it has enough confidence to answer an engineering question and stays quiet when it does not. When uncertain, it can send Smith a direct message saying, 'I think I know the answer to this, but I'm not sure,' and ask him to confirm before replying publicly. Engineers can inspect tasks and previous runs in the UI, but Smith argues that the agent should appear in the tools where teams already work, such as Slack or Microsoft Teams.
"Coding was never the big bottleneck. A lot of it was really around how do we actually run these things in production."02:18
Who should watch
Your team ships frequent code, feature flags, or infrastructure changes that do not receive the same monitoring as ordinary CI/CD releases.
Engineers spend time preparing handoffs, checking dashboards, answering recurring Slack questions, or watching systems after a change.
You are building an agent harness and need a way to add production context, system knowledge, and operational tasks to it.
