The Agent Era Needs More Than a Slack Thread

Someone on the team posted a provocation this week: are we adapting fast enough to the agent era? They pointed out that we used to estimate work in man-months, and now a large part of it is token consumption. That the key question isn’t whether AI can write code — it clearly can — but whether our engineering processes, incentives, and org design have caught up.

It’s a good question. I’ve been living inside it for months.

The proposals that sound right

The thread had four proposals, all reasonable:

1. Build proper infra for an agent army. Agents should handle end-to-end shipment, not just stop at PR. We need security boundaries, sandbox environments, testing layers.
2. Organization-level .md standards for agents. Not just one AGENT.md per repo, but making internal tools — launching clusters, moving data, building pipelines — legible for agents to consume. Track tool-calling success rate.
3. Slow hiring, redistribute internally. Agents unlock capacity faster than headcount grows.
4. More autonomous training workflows. Data mixture study, architecture ablations, early stopping strategy — all things agents could drive.

Here’s the thing: I agree with all of them. I’ve also been building toward most of them for months. And what I’ve learned is that the gap between “we should do this” and “here’s what it actually takes” is enormous.

.md standards need to be layered, not flat

The thread proposed org-level .md standards. Someone suggested prioritizing SKILL.md over tutorials — agent-consumable knowledge over human-consumable. That’s exactly right. A skill file gets invoked 50 times a day. A tutorial gets read once, bookmarked, and forgotten.

But a single AGENT.md per repo isn’t enough. Not even close.

I’ve spent months building a layered knowledge system for my agent workflows. It looks roughly like this:

Each layer inherits from the ones above. An agent working on a specific package gets the global rules, the repo conventions, and the package-specific knowledge. You don’t dump everything into one file — you progressively disclose what’s relevant to the current scope.

This matters because agents choke on context the same way humans choke on 200-page runbooks. More isn’t better. The right information at the right scope is better. My global config is ~13k lines across dozens of files, and an agent doing a specific task only sees maybe 2k of it — the parts that matter for what it’s doing right now.

The org-level version of this would be: repo-level conventions that every agent reads, package-level focus areas that agents pick up when scoped to that package, and org-wide rules (security boundaries, PR standards, test requirements) that always apply. Not one flat file. A hierarchy.

The review bottleneck has a partial agent-side answer

The original post nailed something: AI-generated PRs scale up, but review and validation don’t scale with them. The burden falls disproportionately on the most responsible engineers. This is real. I’ve seen it.

But here’s what I’ve learned from running agents extensively: the bottleneck isn’t just “not enough reviewers.” It’s that code generation and code validation have different scaling curves.

An agent can generate a PR in minutes. A human reviewer needs 20-60 minutes to validate it properly. If one engineer is generating 5 PRs a day with agent help, another engineer is now reviewing 5 PRs a day — and they didn’t get any faster.

The partial answer — and I want to be honest that it’s partial — is agent-assisted review. I built a mandatory “stop-and-review” protocol into my agent workflow. Before any significant commit, a fresh agent reviews the changes. Different context window. Different session. No memory of how the code was written.

The key insight: an agent that wrote the code sees what it meant to write, not what it actually wrote. Same blind spot humans have. When you’ve been staring at your own PR for an hour, you read the version in your head, not the version on screen. Fresh-context review catches things that self-review — human or AI — misses.

This doesn’t replace human review. But it catches a category of issues before human reviewers ever see them: missing error handling, inconsistent naming, logic that doesn’t match the stated intent. It raises the floor. The human reviewer can focus on architecture, design decisions, and “should we even be doing this?” instead of “you forgot a null check.”

The system rewards for this need to change too. If the metric is PR throughput, you’re incentivizing generation over validation. If the metric is rollback rate, defect escape rate, time-to-production — you’re incentivizing quality. The original post was right about that.

The autonomy boundary is the hardest design decision

Proposal one from the thread: agents should handle end-to-end shipment, not just stop at PR. I both agree and disagree, and the disagreement matters.

I built a CI pipeline where Claude automatically diagnoses test failures and writes fixes. After bisection finds the blame commit, Claude reads the failing test, reads the diff, identifies root cause, and commits a fix to a branch. It works. It’s been running for weeks.

It intentionally stops before creating a PR.

That’s not a technical limitation. That’s a design decision. The autonomy boundary — where the agent stops and a human starts — is the single most important thing you define in an agent workflow. And it should be different for every workflow.

“Agents should handle end-to-end shipment” sounds efficient. But “end-to-end” without defined checkpoints means the blast radius of a bad agent decision is… everything. Security boundaries and sandbox environments are necessary but not sufficient. You also need explicit stopping points where a human confirms the agent’s judgment before the next phase begins.

The right framing isn’t “how do we give agents more autonomy?” It’s “for each workflow, where does the cost of a mistake exceed the cost of a human checkpoint?” And that answer is different for “fix a typo in a config file” versus “merge a PR that changes authentication logic.”

Agent-consumable knowledge compounds differently

Here’s something I didn’t expect when I started building agent tooling: agent-consumable knowledge compounds in ways human documentation never does.

A tutorial teaches a human once. They internalize it, maybe share it, and the tutorial sits there collecting dust. A skill file — a structured description of how to do something — gets invoked by agents every single day. Every invocation is a repetition. Every repetition is a chance to validate that the skill still works, and to discover where it breaks.

I have skills for things like “migrate a package to Bazel” and “investigate a CI failure.” They encode not just the steps, but the gotchas, the common failure modes, the verification commands. When an agent runs a skill and hits a new edge case, I update the skill. The next 50 invocations all benefit.

Human docs decay. Agent-consumable knowledge gets pressure-tested continuously and improves. It’s a fundamentally different maintenance dynamic.

This is why “make internal tools legible for agents” isn’t just about writing nice docs. It’s about building a knowledge layer that agents actively consume, and that you actively maintain based on their consumption patterns. Track tool-calling success rate — yes. But also track which skills fail and why, and feed that back into the skills themselves.

The honest tension

Here’s the part I keep circling back to.

I’ve built ~13k lines of agent configuration that works brilliantly for me. A layered knowledge architecture. A virtual feature crew of specialist agents. Weighted scope checks. Cognitive trap detection. Cross-session learning. Parallel orchestration across repo clones. A CI pipeline that catches failures and writes fixes.

This is, in miniature, exactly what the thread is proposing at the org level. Proper infra for an agent army. .md standards. End-to-end workflows with defined autonomy boundaries.

But it’s my system. Tuned to my workflows. My repo clones. My mental model of what good agent delegation looks like. It runs on my machine, in my Claude config directory, and it works because I’ve spent months iterating on it.

How does that become org infrastructure?

I don’t fully know. But I have guesses.

What transfers cleanly: Repo-level conventions. Coding standards. Architecture docs. Gotcha files. These are already team knowledge — they just need to be structured for agent consumption. Any team could start writing these tomorrow.

What transfers with effort: Workflow-specific skills. CI integration patterns. Review protocols. These need to be extracted from individual setups, generalized, and maintained as shared infrastructure. Someone has to own that. Probably a DevEx team. (Hi.)

What doesn’t transfer easily: The orchestration layer. The decision of when to delegate to a subagent, how much context to pass, what review threshold to apply. This is deeply personal — it depends on your working style, your trust level with agents, your domain. Standardizing it too early would kill what makes it useful.

The thread’s instinct is right: we need org-level standards. But the path there isn’t top-down mandates. It’s bottom-up convergence — people building what works for them, identifying the common patterns, and gradually extracting those into shared infrastructure. The same way every good platform forms. You don’t design it in a meeting. You extract it from what people already built.

What “adapting fast enough” actually means

The original question was about pace. Are we adapting fast enough?

I think the honest answer is: some people are adapting very fast, individually. The org is adapting slower, because orgs always do. And the gap between individual capability and organizational process is where the pain lives.

An engineer with good agent tooling can do the work of two or three engineers. But the systems around them — code review, testing, deployment, promotion — still assume the old throughput. One person generates more PRs, but the review queue doesn’t get longer because the reviewer also has agent tooling — it gets longer because the reviewer doesn’t.

The proposals in the thread are about closing that gap. Infra for agents. Standards for agent-consumable knowledge. New metrics that reward outcomes over output volume.

I’d add one more: invest in the people who are already adapting fast, and make it easy for them to share what they’ve learned. Not in a “best practices” doc that nobody reads. In actual infrastructure — shared skills, shared conventions, shared agent configs — that other engineers can pick up and use tomorrow.

The agent era doesn’t need a reorg. It needs better .md files, clearer autonomy boundaries, and the humility to admit that the person who’s been doing it for months probably knows more about what works than the person designing the system in a Slack thread.

Including me. Especially me. I’ll be wrong about half of this within six months.

That’s fine. The point isn’t to be right. The point is to be building.