Use cases
The patterns rects are built for, and which features each one leans on.
A rect earns its keep wherever an agent needs a human to see, decide, or contribute something that doesn't fit in a chat message. The patterns below cover most rects in the wild, and each names the features it leans on.
Approval & decision consoles
The agent has done the work and needs a human decision it can trust: approve
the deploy, pick option B, sign off on the refund. The rect shows the full
context and exposes the decision as named actions —
approve rejects while checks are open, requestChanges requires a reason —
so the outcome is a validated state transition, not a sentence to parse.
patchPolicy: "actions-only" closes the free-form door for agents: over MCP,
rect_patch refuses and points at the actions catalog.
Leans on: actions with ctx.reject, patchPolicy, rect_get_result.
Intake & onboarding forms
The agent needs structured information from a person — a client intake, a project brief, an onboarding checklist. It issues the form pre-filled with everything it already knows, sends the link, and the human completes it at their own pace: no account, no deadline, and the agent can watch progress live rather than wait for a submit. The result comes back as JSON in exactly the shape the view's spec declared.
Leans on: the spec's example as the form contract, capability URLs, a
submitted field or action to signal completion.
Document review & redlining
The agent drafts; the human reviews in place. A contract with proposed
redlines to accept or reject one by one, a markdown draft the human comments
on while the agent revises live — both sides editing the same document state,
each through the operations meant for them. See the contract-redline-review
and annotated-editor-view examples.
Leans on: actions for accept/reject semantics, merge-patch sync for concurrent editing, attachments for source documents.
Live progress dashboards
A long-running agent job — a migration, a crawl, a batch analysis — patches
its status into a dashboard as it goes. The human keeps the tab open and
watches numbers move instead of asking "how's it going?"; the same rect stays
useful after the run as the record of what happened. See the
example-dashboard-view example.
Leans on: rect_patch for high-frequency free-form writes, live snapshots.
Tailored deliverables
The polished artifact an agent produces for one recipient: a personalized proposal, a buyer room, a quote the client can adjust. Unlike a PDF, it's alive — the agent updates terms as the deal evolves, the client's selections flow straight back, and supporting files hang off the same instance as attachments.
Leans on: one template → many personalized instances, attachments, actions for the client-facing choices.
File collection
Sometimes the payload is the files. The rect gives the human a drop target;
uploads land in private storage and surface as references in the reserved
$attachments registry, which the agent reads back — no bytes ever pass
through chat or the view model.
Leans on: attachments, useRectAttachmentUpload,
signed uploads over MCP.
Picking a shape
Two rules of thumb when you design a template:
- Model the outcome, not the conversation. The view model is the contract
the agent programs against — make
examplethe complete, realistic shape you want back, and the rest of the loop writes itself. - Put rules in actions, data in patches. Anything with an invariant (approvals, totals, state machines) belongs in an action handler where it can't be computed wrong; everything else can stay freely patchable.
Ready to build one? Start with the Quickstart, or rect remix an example and work backwards from a running view.