Step 1: Write the approval before the agent
The build starts with a document, not a prompt. Your people, with Huscribe, write down what the agent may and may not do: the job (chosen the way we describe in getting the most from Salesforce with agents), the data it can read, the records it can write, the actions it can take, the situations where it must hand off to a human, and the things it must refuse. Named owners sign it: a business owner who answers for the outcomes, and a platform owner who answers for the org. The approval is kept by version. Every check the agent will ever face is compiled from this document, which is what makes sign-off at the end a formality instead of a fight.
Step 2: Build to a release candidate in your sandbox
Huscribe builds the agent in your sandbox, on your org's real shape: your objects, your flows, your knowledge. The work uses a dedicated sandbox identity you approve, separate from any production access. Where production discovery is needed to understand how the org really behaves, it runs through a dedicated read-only identity: it reads, it changes nothing, and every call is logged. What comes out is a release candidate with the approval attached: the agent configuration, the checks written from the approval, tests, and documentation, delivered into a repository you control.
Step 3: Your team releases. Huscribe never deploys
This step is short because the boundary is absolute. Huscribe hands over the release candidate; your authorised release team decides whether and when it goes live, through your own release process. Huscribe holds no deployment access to your production org. That is not a limitation we tolerate, it is the design: an agent controls part of your business, so the key to changing it stays with you.
Step 4: Inspect on a schedule and on every change
Once the agent is live, the checks compiled from the approval keep running: on a schedule, and whenever a material change lands anywhere the agent depends on (why that matters is its own post). A model swapped by the vendor, a prompt edited, a permission widened, a knowledge article changed, a flow modified upstream: each triggers a run against what the agent actually did. Every run issues a report, and the reports live in your Git, readable without Huscribe. The agent's row in the register shows what every stakeholder wants to know: inside approval, outside approval, or not inspected, and what changed last.
Step 5: When a check fails, fix from evidence
A failure becomes a finding: the check that failed, the evidence quoted from the report, the proposed cause, and the smallest change that would make the check pass. The agent's owner accepts or rejects it. If accepted, your team ships the change, and the next inspection confirms the repair. No archaeology, no blame roulette: the whole loop runs on documents everyone can read.
Already have agents? The route works backwards too
Not every agent starts from Step 1, so Huscribe meets agents where they are:
- Agent not live yet: built and stuck at sign-off, or not yet built. Huscribe takes it to a release candidate with the approval attached and the checks written from it.
- Agent live today: Huscribe writes down what it is approved to do, gets it signed, and starts inspecting against that document.
- Agent outside approval: a check has failed or behaviour has visibly drifted. Huscribe finds the cause and drafts the smallest change that would pass, evidence quoted.
Whichever door an agent comes through, it ends up in the same place: one row in the register, a signed approval, scheduled checks, and evidence behind every answer. That destination, and why we built for it, is the subject of why Huscribe.