Discover, Review, Filter: How Every Role Will Manage Agents
We built Actual AI to keep coding agents consistent with a team's architecture. Underneath the product is a three-step loop. Discover: AI reads the team's previous work and proposes the rules it is already following. Review: people accept, reject, edit and collaborate on those rules. Filter: for each task an agent executes, it receives a short set of rules, filtered for relevance.
We used to describe that loop as a software tool. We now think it is something bigger: the operating model for any job in which a person manages agents. Software is just where the agents showed up first. This post makes that argument from three assumptions. Accept all three and the pattern has to be built everywhere.
What the loop looks like in software
How Actual keeps agents on your architecture
01Discover
AI reads your team's previous work, starting with the codebase, and proposes the rules it is already following, with evidence for each.
02Review
People accept, reject, edit and collaborate on new and existing rules, with every version kept.
03Filter
For each task an agent executes, it receives a short set of rules, filtered for relevance by our Skill and CLI.
In software, the rules are architectural decisions, recorded as ADRs (architecture decision records).
- Discover. AI reads previous work and proposes the rules the team is already following, each with the evidence behind it. In software the richest source is the codebase, which is where Actual starts: Server Actions handle form mutations, every image goes through
next/image, email goes through Resend. - Review. People get a dedicated interface for new and existing rules. They accept, reject, edit and collaborate on each one, with comments in context and every change versioned with its history, so what the team believes is written down and nobody has to guess.
- Filter. For each task an agent executes, it receives a short set of rules, filtered for relevance. Our Skill and CLI do the filtering: ask
actual rules select "Add a contact form that emails sales"and the agent gets the rules about Server Actions, email and error handling, not the ones about images or animation.
Now take the software out of it.
Assumption 1: Every white-collar role will manage agents
Lawyers will manage agents that draft and redline. Accountants will manage agents that reconcile and close the books. Marketers, recruiters, analysts, support leads and procurement teams will each run agents that do the first pass of their work. The job moves from doing the work to directing it and checking it.
You don't have to believe this happens next quarter. You only have to believe the direction is set. It is already true for software engineers, and every other knowledge role is on the same path, a little behind.
Assumption 2: You manage agents by setting rules, not by making decisions
A person can carefully approve a few dozen decisions a day. A fleet of agents makes thousands. If every one of them waits for a human, the human becomes the bottleneck, and the agents are just a very fast way to fill an inbox.
Good managers already know the way out. A controller does not approve every expense; they write the expense policy. A general counsel does not read every NDA; they write the playbook. A rule is a decision made once and applied every time after. It scales with the number of agents. The human doesn't.
So managing agents well means writing rules. The question is where the rules come from.
Assumption 3: People can't recall the rules they actually use
Ask a senior lawyer for their contract rules and they will list ten. Watch them redline a contract and they will apply two hundred. Expertise is mostly tacit: rules applied so often they stopped feeling like rules. People are far better at recognizing a rule when they see it than at recalling it in front of a blank page.
The rules aren't lost, though. They are written into the work: past contracts and redlines, closed books, approved campaigns, resolved tickets, the codebase. Everything a team produces is a record of the decisions it made.
Why the pattern follows
Put the three assumptions together and each step of the loop becomes unavoidable.
- Discover is required because agents need rules (assumption 2) and people can't produce them from memory (assumption 3). The only complete source is previous work, and it lives in many places: the finished work itself, documents and templates, tickets, email and chat threads, review comments, meeting notes. So AI has to read across those sources and propose the rules the team is already following.
- Review is required because a proposed rule is a guess. People can't write the rules from scratch, but they are very good at judging them. So the system has to put each proposal in front of the people who own it, let them accept, reject, edit and collaborate on it, and keep the history when the answer changes. The reviewed set becomes the team's system of record.
- Filter is required because that system of record grows. A team that has reviewed its rules for a year has hundreds of them, an organization has thousands, and an agent doing one task needs a handful. So for each task an agent executes, it should receive a short set of rules, filtered for relevance to that task.
The same three steps show up in every role:
| Role | Previous work to discover from | Review | Filter for a task like |
|---|---|---|---|
| Legal | Past contracts, redlines, playbooks | Counsel approves fallback positions | "Redline this vendor MSA" |
| Finance | Closed books, reconciliations, memos | The controller approves policies | "Close October for the EU entity" |
| Marketing | Approved campaigns, brand feedback | The brand lead approves voice and claims | "Draft the enterprise launch email" |
| Recruiting | Scorecards, past hiring decisions | Hiring managers approve the bar | "Screen these backend candidates" |
| Support | Resolved tickets, escalations | The support lead approves policies | "Answer this refund request" |
Why filter instead of loading everything
The tempting shortcut is to skip the third step. Context windows are huge now, so why not put every rule in front of every agent? Because of a principle worth stating plainly:
Given the same relevant information, a model's usefulness is inversely proportional to the size of its context.
Hold the useful information fixed, add irrelevant tokens, and the results get worse. Models miss facts buried in the middle of long inputs, a pattern documented in Lost in the Middle, and Chroma's context rot study found performance falling as input length grows, even on simple tasks. Every extra token also costs money and time. A rules file that works at 20 rules quietly fails at 2,000: the agent follows some, misses others, and nobody can tell which.
So filtering is not an optimization. It is what makes a large body of rules usable at all.
Who watches the inference companies?
There is a second reason the filter should not belong to the model provider. Inference companies are paid by the token. More context, longer reasoning and more agent loops all mean more revenue. That isn't a conspiracy, it is how the meter works, and it shapes the defaults: bigger windows, "just include everything", agents that re-read the whole project on every task.
Your incentive runs the other way. You want the fewest tokens that carry the right rules. When the company selling the tokens also decides how many tokens each task needs, nobody is watching the meter on your behalf. The layer that decides which rules an agent sees, and so how much context it burns, should belong to the team that owns the rules and work across every model rather than inside any one of them. That is how we built ours: the same reviewed rules, served to Claude Code, Codex, Cursor or a direct API call, filtered before the agent ever sees them.
Software is first, not special
Software got here first because code is the most machine-readable work product there is, and coding agents arrived before the rest. But nothing in the three assumptions is about code. Wherever people manage agents, AI will need to read previous work and propose the rules already being followed, people will need a place to accept, reject, edit and collaborate on them, and every task an agent executes will need a short set of rules, filtered for relevance. We are building that for software architecture today, and we expect to see the same pattern in every role that comes next.
Actual AI reads your team's previous work to propose the architectural rules it already follows, gives people one place to accept, reject, edit and collaborate on them, and hands each coding agent a short set of rules, filtered for relevance to its task.