The Task Is Done. The Responsibility Isn't.

The task may be done. The responsibility is still there.

I think we're still thinking too small about agents.

The arrangement keeps looking the same: I give an agent a task, it does the task, and then it waits. Maybe it writes code, runs tests, updates the docs. Useful work. But when the interaction ends, who's keeping track of what happens next?

Usually, me.

I manage engineers. When I hand a senior engineer a system, I expect them to understand what we're trying to accomplish, know the weak spots, and notice when something changes. Sometimes that conversation starts with, "We have a problem." Sometimes it starts with, "I already handled it." Either way, somebody was paying attention without waiting for me to ask.

That's a huge part of delegation: getting something off my mental stack. I still set priorities and make the calls. I shouldn't have to remember every unfinished thing just to keep it alive.

With agents, I can end up with more features, more pull requests, and twenty more things to remember. The agent made me faster. It also made my blast radius bigger.

Tasks end, services don't

To be clear, "the agent owned it" doesn't excuse a service failure. A human stays accountable for the system, for what the agent is allowed to do, and for what we accept from it. What I want to delegate is the continuous work of looking after it: keeping context, investigating changes, tracking commitments, and bringing me the decisions that actually need me.

"Review this pull request" ends. "Help keep this service reliable and compatible" keeps going after the release ships and everybody moves on.

But "keep it healthy" isn't enough on its own. Which requirements matter? What can the agent change? What does it escalate? Vague instructions don't become good management because we gave them to software.

The agent also needs a maintained understanding of what's actually happening, not just a chat history. It has to tell what we decided from what shipped, what we believe from what we verified, and what's finished from what's waiting on somebody else. "The tests passed Tuesday" is history. "The tests pass against the current dependency" needs current evidence. We already have monitoring, CI, scanners, and issue trackers. The opportunity is connecting them to an ongoing objective, and that's as much a product and infrastructure problem as a model problem. State, permissions, and follow-through can't depend on a conversation staying open.

Somebody has to notice

And sometimes the agent needs to start the conversation, because sometimes I don't know there's a problem. That's the whole fucking point. If I have to notice every risk and kick off every investigation, I'm still managing the entire system. I just have a very fast keyboard.

Say an agent helps maintain an identity service. Another team changes a shared API contract. Integration tests start failing intermittently, staging throws serialization errors, and nobody has opened a ticket for us. Within its authority, the agent connects those signals, traces them to the contract change, adds regression coverage, and verifies a patch in staging. Then it comes to me:

"The upstream contract changed. I have a tested patch ready. Production needs your approval. I've opened an issue with the owning team and I'm tracking the permanent fix."

Great. But the important part comes later. Two weeks on, when the upstream fix ships, the agent should still know why our workaround exists. That's exactly the kind of context that usually lives in one person's head, or nowhere. It should verify the fix, clean up, and keep the issue open until the workaround is gone. A passing patch shouldn't erase the obligation that came with it.

That's continuity of responsibility.

Judgment, kept bounded

It also takes judgment. I don't need an interruption for every warning. Sometimes the right move is to gather evidence, note the change, or leave it alone. And sometimes it's telling me the thing I asked for is the wrong thing. Proactivity without judgment gives me a chatty monitoring system, and now I'm supervising its anxiety.

Authority needs boundaries, too. Investigating failures and deploying to isolated environments might be fine; production needs approval. Inside those lines, the agent should work without me approving every keystroke. And "I requested approval" is a status, not an outcome. The agent still has to track the decision and escalate when waiting starts to cost something.

Same goes across teams. Identity can't declare checkout somebody else's problem when its change breaks auth there. Opening a ticket isn't somebody accepting responsibility. Let's not automate the same organizational bullshit and call it progress.

Quiet isn't fine

There's also a risk in getting exactly what I'm asking for. The agent quietly runs a service for six months, people stop understanding it, and then it hits something it can't handle. Nobody knows what it's been doing. That's not successful delegation. That's harder recovery.

So decisions, changes, open risks, and the reasons behind temporary fixes have to stay inspectable. A human should be able to take over without reconstructing six months of chat logs. The agent's own health should be visible, too. Silence can't mean either "everything's fine" or "the thing watching everything is broken."

What I want is the equivalent of a weekly one-on-one. What changed? What did you handle? What's getting worse? What needs me? Show the evidence. I want less to carry, not less visibility.

And none of this should require every user to become an expert in prompting, orchestration, memory, and permissions. Defining an outcome is reasonable. Building a management system just to keep the agent working is homework.

What good actually looks like

Which means we should judge these agents differently. Finishing a hard task is one thing. Keeping a service healthy for months while requirements and dependencies shift is another. Did it catch real problems, finish the follow-through, stay within its authority, and leave the system understandable? How much of my attention did it eat? A hundred tickets and a second management job aren't leverage.

Six months after handing over responsibility, I want to ask, "What's going on with this?" and get a current, evidence-backed answer, with the unfinished work still visible. I want somebody to notice when the temporary fix becomes permanent, the dependency never arrives, or the requirement changes underneath us. I shouldn't have to reopen the conversation for it to matter again.

A good engineer does more than write code. They use judgment and keep unfinished work from quietly disappearing. Give agents a clear scope, bounded authority, and a human who stays accountable. Then expect them to keep looking after the work.

The task may be done. The responsibility is still there.