What a few weeks of goal-oriented agent work taught me — most of which I already knew from running a company.
The six-minute fortnight
A few days ago a coding agent on one of my projects estimated a piece of work — a server scaffold, fifty-odd tools, a container build, a manifest, smoke tests — at "two to three weeks." It shipped in about six minutes.
That number isn't a brag and it isn't really the point. Over the last two weeks the same project merged 150 pull requests, roughly ten a day. The point is that the model didn't change over that fortnight. What changed was how I manage it.
I spent years running a company before I went back to building things. I expected agentic coding to feel like programming. It turned out to feel like management — and not loosely. Every productivity gain I've made in the last month has come from importing something I already knew about running people, and the things that went wrong went wrong for reasons any manager would recognize on sight.
This is a field report on that, including the parts that didn't work.
From giving tasks to giving goals
The default way you work with a coding agent is a loop: you write a prompt, it does a task, it returns, you write the next prompt. It's fast and it's satisfying and it has a hard ceiling — you. You are a human being hand-feeding work to something that can move far faster than you can think of things for it to do. You've made yourself the bottleneck and called it being in control.
The first real change was deleting that loop. I now keep a goals file: five strategic goals on a 30-to-90-day horizon, each with a written, verifiable done-state. The agent reads that file when it's idle and picks the work itself.
This is not novel. It's management by objectives — Drucker, 1954. You don't tell a good team what to do today; you tell them what winning looks like this quarter and let them choose the moves. Writing that goals file felt exactly like writing objectives for a department. The hard part wasn't the agent. It was me having to actually decide, in writing, what mattered — because vague goals produce vague work from agents for precisely the same reason they do from people.
The manager seat
The second change followed immediately. The agent can dispatch other agents — spin up sub-agents, hand each one a scoped job, let them run in parallel.
The moment that's true, the main session stops being a worker and becomes a manager. And the thing you optimize flips. I no longer try to make the main agent finish its own task faster. I try to maximize the number of independent work-streams in flight at once. Serial throughput is irrelevant; parallel thread count is everything.
Any manager who's been promoted out of an individual-contributor role knows this transition and knows it's uncomfortable. Your instinct is to grab the keyboard. The job is to not grab the keyboard. Span of control is a real constraint with agents too — I cap concurrent sub-agents at eleven, because past some number a manager is just generating chaos they'll have to reconcile later.
AFK as an explicit delegation contract
Here's the piece I'm proudest of, and it's the most management-shaped of all.
I have a toggle — call it AFK mode. Flip it on and the session changes posture: it stops checking with me on every decision and runs autonomously against the goals file. Flip it off and it switches back to attended mode and hands me a report.
What makes it work isn't the autonomy. It's that the autonomy is bounded by an explicit, written contract:
- A refuse-set — the short, specific list of decisions that are never delegated. Security-sensitive code. The rule file itself. Anything that spends real money. Anything touching production data destructively. This is the list a good manager gives a deputy before going on leave: here's what you can decide; here's what waits for me.
- A concurrency cap — the span-of-control limit, written down.
- A pre-AFK walkthrough — before I go offline, the agent walks every goal and surfaces every dispatchable piece of work, and I pre-authorize them in a single pass. This is the handoff meeting you have on the Friday before vacation. It even reasons in chains: "if I dispatch this, then in two moves I'll need to do that — can I pre-authorize the whole sequence?" Looking three or four moves ahead so the deputy doesn't stall waiting for you is, again, just good delegation.
The insight that took me a while: delegation isn't the absence of control. It's control relocated — from supervising each action to defining the boundary in advance. The refuse-set is more rigorous than the ad-hoc "check with me if you're unsure" I'd have given a human, and it works better for exactly that reason.
Reporting up: APPLIED / QUEUED / BLOCKED
When AFK mode ends, the agent doesn't dump a log. It hands me a digest in three buckets:
- APPLIED — done, landed, here for your information. Scan it.
- QUEUED — finished, but needs your approval before it can go live.
- BLOCKED — stuck, and needs you specifically to unstick it.
I didn't design that format. I recognized it. It's how a good report briefs a manager who's been out: here's what I handled, here's what's waiting on your sign-off, here's what only you can move. And the discipline that matters most is the third bucket — BLOCKED is the only thing allowed to interrupt me. Everything else waits for when I choose to look. A status report whose every line is an interrupt isn't a report; it's a manager who never actually delegated.
The reversibility gradient
Not every decision deserves the same gate, and pretending otherwise just recreates the bottleneck.
So decisions are graded by blast radius. Low-stakes, reversible changes — tracking files, internal docs, the work queue — the agent finalizes on its own. Code, database migrations, anything security-adjacent — those always route to a human for approval. The gate matches the cost of being wrong.
And there's one hard line underneath all of it: the agent cannot modify the rule file, and it cannot modify its own definition. It operates under the rules; it does not get to rewrite them. That's not a performance optimization. It's separation of powers — the oldest idea in governance. An agent that can expand its own authority doesn't have authority; it has a loophole.
Institutional memory
Everything durable lives in a file. The active work queue, the longer-horizon backlog, the lessons learned, the calibration data, the goals. The operating rule, stated bluntly in the project's own documentation, is: if it's not in a file, it didn't happen.
This sounds like process hygiene. It's actually the thing that makes the whole model survive. An agent's working memory resets. A new session, or the same session after its context compacts, knows only what's written down. So the written record isn't documentation about the work — it is the organization's memory, and it has to be complete enough that a competent stranger could pick up cold.
Which is, of course, the difference between a company that runs on tribal knowledge and one that runs on institutional memory. With people you can limp along on the former for years. With agents the reset is brutal and immediate, so you're forced to build the latter on day one. The constraint turns out to be a gift.
The agent learned to estimate
That two-to-three-weeks-became-six-minutes gap wasn't a one-off. Early on, the agent's estimates — when it anchored on how long a human developer would take — ran long by factors of 100 to 1000×. Useless for planning.
So the project keeps a calibration log: every estimate recorded before the work starts, the actual derived from commit history, a correction factor computed per category of task. Over time the agent's sense of its own velocity converged on reality.
This is performance management. Not the punitive kind — the useful kind: a team measuring its own throughput honestly enough to plan against it. The two disciplines that made it work are the two that always make it work. Record the estimate before you start, so you can't flatter yourself afterward. And anchor on the right reference class — the agent had to stop comparing itself to a human developer, the way a new team has to stop estimating in some other team's story points.
The parts that didn't work
If I only told you the wins, this would be marketing. The failures are more instructive, and every one of them is a management failure with a familiar name.
The idle delegate. During one AFK session the agent sat idle for half an hour while four of its five goals had work ready to dispatch. It wasn't blocked. It was being cautious — deferring things as "probably better to wait." This is the new deputy who under-uses the authority you explicitly gave them, and it's arguably the most common delegation failure there is. The fix was a written rule: idle time, when the refuse-set isn't the thing stopping you, is itself a failure — name the real blocker or dispatch.
Stopping to ask the empty room. Early on, the agent paused mid-run to ask me a clarifying question — while I was offline, which was the entire premise of the run. It waited. The session burned hours having decided nothing. The fix is the one every manager eventually gives: when you're genuinely unsure, pick the safer, more reversible option, write down why you chose it, and keep moving. A blocked question nobody is there to answer is worse than a defensible decision.
Two people, one document. Two sub-agents, dispatched in parallel, edited the same working files and silently clobbered each other. The fix was workspace isolation — each agent gets its own copy. It's the version-control problem, but it's also just coordination: two employees unknowingly assigned the same task, producing collision instead of output.
Theorizing instead of looking. A deployment problem got diagnosed wrong for two days — a pile of plausible hypotheses about infrastructure — when the actual cause was a one-line bug that five minutes of reading the right log would have shown. Nobody had read-access to that log. The lesson, now written into the project's standing rules: when something has been a mystery for more than a day, the highest-leverage move isn't a better theory, it's getting whoever's stuck the access to look. Managers burn weeks this way. So do agents.
Notice the pattern. None of these were model failures. They were organizational design failures — and every fix is a practice you'd find in a decent management handbook.
You build the office, not the employees
Here's the conclusion I didn't expect.
The temptation in this field is to wait for a smarter model. But the smarter model is coming regardless — it arrives on someone else's schedule, and when it does, it drops straight into this structure and gets better for free. The goals file, the delegation contract, the reporting format, the reversibility gradient, the institutional memory, the calibration loop — that is the durable asset. That's what compounds. You are not building the employees. You are building the office they work in.
And the office you build is just an organization. I went looking for novel techniques to manage AI agents and found that I didn't need any. I needed management by objectives, span of control, delegation with a written boundary, status reporting, separation of powers, institutional memory, and honest performance measurement.
The medium is genuinely new. The model resets its memory, moves a thousand times faster than a person, and works at three in the morning. But the medium turned out to be unforgiving in a useful way: it punishes vague goals, fuzzy delegation, and tribal knowledge instantly, where a human organization can absorb those flaws for years. So it doesn't let you skip the management. It makes you do the management well.
We didn't invent a way to manage agents. We were forced, finally, to manage properly.