Most teams size up agent autonomy by asking whether the model is smart enough yet. PostHog says that question is the wrong one to ask. In a July 27 newsletter post, the analytics company argued that autonomy should be assigned per task, not per model, and that betting on a smarter model to make a workflow safer is a category error.
The stakes are practical. Engineering teams already run the same frontier model across dozens of workflows, and a single capability jump does not make all of those workflows equally safe to hand off. Treating autonomy as a model property means either under-using agents everywhere or over-trusting them somewhere, and PostHog’s framework is built to prevent the second failure.
PostHog’s test rests on two questions for any given task: how cheaply can the output be checked, and how costly is it to undo if the agent gets it wrong. Deterministic work like passing tests is cheap to check; subjective work like judging whether a variable name reads clearly is not. A pull request sitting in draft is cheap to reverse; a change that ships to production data is not. Crossing those two axes produces four tiers.
- Agent as assistant (hard to check, costly to undo): work too risky to hand off. When a PostHog engineer named Dylan rebuilt the company’s feature flag targeting engine, an assumption baked into every live customer flag had to move with it. Nothing about that migration could be verified with a grep, so he did the core rewrite by hand and only delegated the safer job of copying the new logic into PostHog’s SDKs for JavaScript, PHP, Ruby, and Flutter.
- Human in the loop (hard to check, cheap to undo): subjective calls that stay in draft until a person signs off, so an “undo” just means another pass. A readability cleanup by another PostHog engineer, adding comments and swapping strings for an enum, fits here because no automated check can grade good taste.
- Agent delegation (easy to check, costly to undo): PostHog calls this the default ceiling for most engineering work today. An agent named Robbie rewrote PostHog’s SQL parser in Rust and barely reviewed the code himself, since the test suite served as an oracle. Because that parser sits underneath every query PostHog runs, the change still went through a production shadow mode before a staged cutover.
- Self-driving (easy to check, cheap to undo): dependency bumps, lint fixes, and test coverage additions run without supervision. PostHog’s Scouts, agents it shipped last month that work on a schedule and open pull requests based on what they find in product data, live at this tier.
PostHog also builds guardrails to move work down the risk axis rather than waiting on model progress: LLM-as-judge scoring for subjective checks, scoped success metrics as a stand-in for taste, custom skills that encode team conventions, and StampHog, its own PR-approval agent, which routes anything matching a deny-list of risky keywords straight to a human.
The framework’s real implication is that “are agents ready” cannot have one answer inside a company, because two teams running the identical model sit at different tiers depending on what they touch. A support-macro generator can run self-driving while a billing-schema migration stays at assistant level, on the same model, on the same day. That argues for sequencing rollout by task rather than by model access: start by automating the cheap-to-check, cheap-to-undo backlog, then spend engineering effort on the guardrails (feature flags, staged cutovers, judge models, deny-lists) that pull specific hard-to-undo tasks down into delegable territory.
Teams planning their next quarter of agent rollout should audit their own backlog against these two axes before buying a bigger model, and pick one Level 1 or Level 2 task where a guardrail, not a model swap, would unlock the next tier.
PostHog published this framework in its newsletter on July 27, 2026.
