Why AI Agents Need a Draft Layer
Agents can create business data faster than people can review it. A draft layer turns that speed into a safe, useful product.
I work with AI agent integrations most days. We connect agents through frameworks such as Mastra, direct LLM integrations, and tool APIs. Once connected, an agent can read the same business data a person uses and act on it much faster.
A person might spend a day preparing a large set of CRM posts. An agent can prepare the batch in minutes. That speed is useful, but it is easy to confuse generated work with finished work.
An agent can misunderstand the task, delete the wrong content, or create a large amount of low-quality material before a person has time to react. I care less about whether an agent can complete an action than whether a person can verify the result before it becomes real.
For many business applications, that requires a draft layer.
Code agents already have one
Tools such as Cursor and Claude Code write directly into a codebase. When I use them, I can still inspect a diff, run tests, revert a change, or review a pull request.
That is already a draft system. The generated work stays visible and reversible before it reaches production.
Business applications often give agents APIs that write directly to live records. There is no equivalent of a diff or pull request. The agent moves faster, but the user loses the review boundary.
A draft layer creates a simple loop: the agent generates, the system validates, and the person approves.
Andrej Karpathy described a related direction in Software Is Changing (Again): partially autonomous products need custom interfaces that make human verification fast.
This is the part I think many agent products are missing. API access lets an agent do more work. A well-designed GUI lets the customer understand and control that work. Companies that solve both sides can turn agent speed into real customer value.
Drafts are an architecture decision
Adding a draft status is easy. Building a useful draft-driven system is not. Three parts of the product have to support it.
1. The interface
Users need to understand what the agent changed, review many items together, edit exceptions, and approve or reject work without opening records one at a time.
If an agent creates 100 items and the interface requires 100 separate detail pages, the agent saved generation time but moved the cost into review.
Bulk actions, clear status filters, change summaries, and inline editing matter more than an impressive agent animation. For some products, a detail drawer works better than a separate page because users can inspect an item without losing the batch they are reviewing.
2. The data model
Drafts become expensive when one published record owns a large, tightly coupled graph of data.
Keep reusable core data centralized and reference it from the workflow record. Consider a CRM ad:
The ad configuration can be reviewed and reused while the CRM ad carries workflow concerns such as campaign, owner, and status. A draft can point to the same stable concepts instead of copying a web of related tables.
This is not a rule that every product needs one generic content table. It is a reason to separate reusable content from publication state. If each published row has twenty required relationships and every relationship must be duplicated for a draft, draft support will become fragile.
3. The customer
Not every customer wants an agent in the critical path. Some will trust suggestions but not autonomous changes. Others will see mandatory approval as friction.
The level of autonomy should match the task and the customer:
- Suggest only
- Create drafts
- Publish after validation
- Publish automatically within explicit limits
Do not build autonomy because the technology makes it possible. Build the review boundary customers need for the risk they are accepting.
Preventing AI slop
A draft table does not prevent low-quality output by itself. It can become a waiting room full of content nobody wants to review.
The system also needs:
- constraints before generation
- deterministic validation where possible
- duplicate detection
- limits on batch size and permissions
- a clear summary of what changed
- rejection feedback that improves the next attempt
- audit logs for who generated, edited, approved, and published each item
The goal is not to make bad content easier to store. It is to make good work faster to verify and bad work cheap to reject.
The practical test
Before giving an agent write access, I would ask four questions:
- Can the agent write to a reversible state?
- Can the user review its work at the same scale the agent creates it?
- Does the data model separate content from publication workflow?
- Do customers actually want this level of autonomy?
If any answer is no, I would fix that boundary before giving the agent more freedom.
My main point is simple: agent capability is incomplete without a review interface. Agents need structured data so they can work quickly. People need a GUI that helps them review work at the same scale. The draft layer connects those two needs.