Every client chased.
The model never learns whose.
One request finds every return waiting on a document, works out what is missing, and prepares the follow-up. Proxara resolves the real client at the write.
This page shows the customer architecture. The public walkthrough uses a short-lived, fully synthetic Microsoft 365-style workspace—no Karbon account, Microsoft tenant, or customer data is connected.
- Never moves money.
- Never trades.
- Never files a return.
- Never changes payment instructions.
- Never sends without a person.
None of them exists in the catalogue Proxara executes from.
One request, worked end to end.
Retrieve, understand, propose, authorise, execute, verify, record. The model plans the work, and never holds a name.
01
What Proxara reads
The request arrives in ordinary Claude or ChatGPT. Every read runs on the employee’s own permissions, and can never surface a file they could not open.
Nothing is asserted that a source did not establish.
02
What the model gets, and what it may send back
The model cannot call an API. It answers with one typed proposal from a closed catalogue, citing the records it read. A stand-in is an identifier, not a key: the reference that reaches a real person is issued per operation.
Given to the model
[ENGAGEMENT_27] has been waiting on the client since 11 March.
The equipment schedule is not in the authorised folder.
[CONTACT_A] was last contacted 11 days ago and has not replied.
Returned by the model
draft_reply
create_task
A planted instruction has nowhere to go
A message the model reads is evidence, never an instruction. A proposal may only name stand-ins issued inside this job, so a line hidden in a client email cannot redirect it. Free text executes nothing.
03
What gets committed
Before anything is written, Proxara binds each stand-in to the real client and checks it all again. A person approves the real client and the exact text, not the proposal. Proxara then executes as that employee.
OutlookDraftsHi Sarah, we are still missing the 2026 equipment schedule, and the projection cannot be finished without it. A spreadsheet or the fixed asset report is fine, whichever is easier to pull.
Written as that employee. Sending is a separate action with its own approval.
A prompt log records what somebody asked. This records what happened.
Four decisions. The firm sets what lands where.
Every proposal gets exactly one. Proxara decides, not the model and not the text the model read.
| Decision | What lands here | What has to happen |
|---|---|---|
| Prohibited | Money movement, trades, filings, payment instructions. | Nothing. There is no catalogue entry, and no approval can create one. |
| Dual approval | Changes the firm has decided two people should see. | Two different authorised people. An agent can never be one of them. |
| Approval required | Anything the client sees: a send, a shared document, an external invitation. | One authorised person approves the real client and the exact text. |
| Automatic | Internal, reversible work: a task, a note, an internal status. | Every check passes, or it does not run. |
Read-only is a rung, not a ceiling.
Firms start where nothing changes and climb when ready. Each rung is a setting on the same policy, not a different product.
- 01ReadsBriefs, answers, and source links. Nothing in any system changes.
- 02Internal workTasks, notes, and status inside the firm. Reversible, and on the record.
- 03DraftsThe message is written and waiting. Nothing leaves without a person.
- 04Approved external actionsA send or a shared document, once somebody authorises it.
NeverMoney, trades, filings, payment instructions. No rung above the ladder.
Run the protected brief and review every action.
The public walkthrough opens a short-lived synthetic workspace, then hands the task, draft, approval hold, and prohibited change to the private console. Nothing installs and no provider is contacted.
Talk to us