A pull request may be the best interface software accidentally gave AI agents.
It names the exact repository and branch. It shows what changed. The work stays off main while people argue about it. If the branch moves after somebody reviewed it, the approval can go stale instead of quietly applying to different code.
Then agents wandered out of GitHub.
Figma now lets an agent write native frames and components to the canvas. Notion MCP lets AI apps create and edit pages. Lovable's MCP can build, inspect, and deploy projects. Framer now exposes APIs for agents to manage branches.
That leaves an awkward gap. The agent can do the work, but the person may have nothing useful to review.
Approve what, exactly?
An Approve button can pause an agent. That part is becoming a normal framework feature. The OpenAI Agents SDK can interrupt a tool call, keep its state, and resume after a person accepts or rejects it.
Useful plumbing. Still, the person needs to know what the button means.
Which exact artifact can change? What version did the agent inspect? Is the evidence a real provider diff, a preview, or the agent's own summary? Does Approve edit the draft, merge it, or publish it to customers?
If the card cannot answer those questions, the person is approving a verb.
An account is too much
The first rule we settled on in hilos was that a project room attaches a resource, not an account.
A room can hold one Figma file, one Notion page, a Framer project, or a specific Lovable project. That is the actual project the team is making together. The login stays with the person or workspace connection that already holds it.
The permission from the provider is often much wider. Notion's own MCP guide says the connected tool acts with the person's full Notion permissions. Lovable says its OAuth scope covers the full account, uses real credits, and can reach operations such as deployment and database queries.
A client project sitting in one hilos room should not turn into permission to search or edit every project that login can reach.
The login gets the agent into Notion. The room points it at one page.
Every tool tells the truth differently
The pull request gave us a useful outline. Copying it literally would make half these tools lie.
Framer was the easy one. It now lets an agent create a branch, inspect its changes, make a preview, and merge it. In hilos, an agent works on that branch and brings the preview back to the room. The approval is bound to the exact reviewed contents. If those contents move, the merge stops. Merging the branch still does not publish the site. That needs its own decision.
Notion updates are immediate. There is no branch for us to pretend exists. An agent can stage a proposal against the exact attached page, then the approving person's connected agent applies the scoped change and returns a receipt. The earlier evidence is a change summary because Notion did not give us a native diff.
Paper is stranger. Its MCP server runs on the person's computer and follows the file currently open in Paper Desktop. Before proposing, the agent records which file and target nodes it saw. After approval, it checks them again. If the person switched files or the target changed, the write stops.
Lovable has code diffs and previews, but its MCP has no branch an agent can create and merge before the write. A hilos proposal names the exact editor URL, current revision, intended files, and plan. After approval, the person's agent checks the project again, applies only that plan, then returns the resulting diff and preview. Deploy stays outside that approval.
The button still says Approve. Its promise changes with the tool.
Approval and application are two events
This separation started to make sense when we followed the failures all the way through.
A person can approve a proposal and go to lunch. The artifact may change before the agent picks the work up.
Or a provider call may succeed while its response gets lost. The worker never gets to tell hilos what happened.
Blindly retrying is dangerous. A second call might create a duplicate project or apply the same change twice.
In hilos, the human decision is saved before the provider write starts. One agent can claim the work once. It rechecks the target, acts through the provider's official tool, and sends a short receipt back to the room.
If the outcome is unknown, the approval cannot be spent again. The receipt says so, and somebody checks the provider before another attempt. Sometimes the honest answer is, "We need to look before trying again."
The person needs somewhere to disagree
Most approval prompts appear inside the agent session, in front of the person running it. That works for a shell command. It is weaker when the agent is changing a launch brief or a client site.
The useful objection may come from somebody else in the project room. A designer sees that the empty state is wrong. The client knows the page should stay private.
This is why we put the proposal in the room instead of leaving it inside the agent session. The people with context can question it while the change is still cheap. One named person holds the final authority, but the team can shape what reaches that button.
It is the same idea behind putting plan mode in the room, now applied to work that may never become code.
The room is the review layer
hilos leaves the artifact in its native tool. The room holds the attachment and the proposal. Later, it keeps the decision and whatever receipt comes back.
That gives people and agents one shared loop:
attach → inspect → propose → review → apply
hilos uses the evidence the provider can really supply, then brings it to the people who know whether the change belongs.
Access is getting easy. I suspect we will keep adding tools faster than we learn how to review what they do.
So I keep coming back to one very boring question: when somebody clicks Approve, can everyone in the room explain what will happen next?