The processor who
never drops a file.
Processor works the middle of a deal — the part that is all documents, all chasing, and all detail. It sits in the deal’s Slack channel, files what arrives, says what is still missing, and hands anything consequential back to a person.
Saved progress. Explicit approvals.
The execution layer that keeps agent work moving—with scoped permissions, spending limits, and a record of the task. Starting with the Processor application-readiness pilot in Flows.
Preview before deliveryStart in shadow mode to inspect readiness evidence and proposed operations follow-ups without sending a message.
Approve the exact actionEach Slack delivery requires approval of the message and destination. Permissions and supporting evidence are checked again before dispatch.
Follow the same taskSee progress and model spending as application information changes. Reassess or cancel a task from its run detail.
Workspace setup is required. Broader fleet support is planned; the pilot assesses readiness and prepares operations follow-ups. Financing decisions remain with people.
Act, then flag
Most agent demos fail on the second turn, when the model guesses. Processor is built the other way round: it does the mechanical work without asking, and it stops hard at the line where judgment starts.
It reports on a contract
Every task ends in one of five states. You learn the vocabulary once and you can read a channel at a glance — and so can an auditor.
- FILED
- Everything landed where it belongs. Nothing needs you.
- FILED_FLAGGED
- Filed, but something is off — an unreadable scan, a date that does not line up.
- PARKED
- Cannot proceed without an input that does not exist yet. Waiting, not failing.
- DECISION_NEEDED
- A judgment call that belongs to a human. It states the options and stops.
- FAILED
- The task could not complete. It says why, in one line, without retrying blindly.
Report, don’t redo
If a step already ran, Processor says so instead of running it again. The runner is idempotent and resumable, with the hard gates written in code rather than trusted to a prompt.
The same-account boundary is absolute
It touches one account’s records at a time and cannot reach across. Nothing goes to a borrower, a funder, or anyone outside the channel without a named human approving it.
It knows the procedure
Its knowledge ships inside the deployment: document taxonomy, filing rules, the missing-items contract, and the governance model that decides which actions need approval. Not a system prompt — a versioned library that travels with the image.
What works, and what doesn’t
Processor is built and ready. Review its setup requirements and scope before connecting it to your workflow.
What you get from us
- A Slack app you create in your own workspace (we hand you the manifest — about 10 minutes)
- The channel convention you want: one channel per deal is what it is built around
- Named users, and named approvers for anything that leaves the channel
- Somewhere for documents to live — a per-tenant prefix on our storage by default
What a deployment needs from you
Out of scope today
- Bank-statement spreading is a contract-locked stub, not a working analysis
- Salesforce, HubSpot, and Dropbox connectors are designed but not built
- Funder dispatch — the step that would bill an Origination — has no route yet
- No self-serve deploy button; provisioning runs with us in the loop
Named so a pilot starts with the right expectations
Our own back office first
Processor grew out of our own brokerage workflow. The agent is built; configuring it for your organization means choosing your document stores, permissions, and approvers.