AI Front Desk
Human-in-the-Loop Intake Design: The Agent Proposes, You Approve
How Stage 1 intake review works, what the local harness demonstrates, and what still requires a connected installation.
Quick answer
Human-in-the-loop intake separates preparation from permission to act. In ABH Stage 1, the agent proposes a summary and draft; the owner approves each outbound message. The current local harness demonstrates proposal checks, not connected customer sending. Live approval queues and integrations must be scoped, tested, and verified before release.
Intake is where incomplete information meets an impatient customer. A useful assistant can organize the request without becoming the person who decides prices, accepts commitments, or sends a reply. That separation matters more than how polished the generated message sounds. A confident draft still needs an authorized decision.
How does Stage 1 intake review work?
Stage 1 is the owner-reviewed operating model: the agent prepares, and a person decides whether a message should leave the business. The reviewer checks facts, scope, recipient, and proposed next step. Approval applies to the actual draft, not a broad instruction to handle future conversations however the agent chooses.
A practical review begins with the original inquiry beside the summary. The owner corrects missing facts, rejects unsuitable wording, or asks for clarification. An appointment request remains a request until an authorized person confirms it. An estimate question goes to the person responsible for pricing rather than becoming an improvised quote.
Built today versus planned: the local ABH harness evaluates action proposals and marks consequential ones as pending human approval. It does not connect to customer systems or execute sends. A connected queue that records approval and then releases the approved message is installation work, not a capability demonstrated by those local proposal results.
What should an intake summary contain?
An intake summary should capture the request, relevant context, missing information, and the decision a reviewer needs to make. Keep facts supplied by the customer distinct from suggestions generated by the agent. A short, structured packet is easier to check than a polished paragraph that quietly mixes assumptions with evidence.
| Field | Purpose in the proposed review packet |
|---|---|
| Inquiry reference | Find the original request and its time. |
| Customer request | Describe the stated problem without adding a diagnosis. |
| Known facts | Capture relevant service, location, and requested timing. |
| Missing facts | Identify what the owner still needs to verify. |
| Risk or exception | Flag pricing, urgency, or an out-of-scope request. |
| Suggested next step | Show a draft and the specific approval requested. |
This is a proposed intake design, not a claim that every field is already populated by a connected product. The current runtime returns summaries, proposed tools, arguments, and policy decisions. A client-specific specification must define any extra fields, where they come from, and who can see them.
How are permissions kept outside the agent?
The demonstrated policy gate checks a proposed tool against supported tools, the agent's allowed list, and blocking rules. Unknown tools are denied. Consequential proposals require human approval. The agent's tool interface does not include editing that policy. This is a separate code boundary, not merely a sentence asking the agent to behave.
The distinction is narrow but important. Producing a draft is not permission to send it, and requesting approval is not approving oneself. The local policy also blocks contact-related proposals when an explicit opt-out is present. A human-approval status does not override a hard block. Customer text is evidence to review, not authority to change the workflow.
The code is explicitly a demonstration. Connected authentication, account access, and enforcement in a customer's systems still require installation-specific implementation. A simulated policy decision is not evidence that a live inbox, calendar, or customer database has been safely connected.
What are the five governance gates?
ABH's documented engineering standard names five gates: specification, permission, automated verification, independent review, and release. They describe how a change should earn acceptance. They are not five deployed security products, and the existence of the written framework does not prove that an individual installation has completed every gate.
- Specification: define the outcome, acceptance criteria, scope, and actions that must wait.
- Permission: give the workflow only the tools required for its agreed task.
- Automated verification: run relevant checks against expected behaviour and known failure cases.
- Independent review: have a separate reviewer examine the change, risks, and evidence.
- Release: require explicit owner authorization, supporting evidence, and a rollback plan.
For intake, that means deciding what counts as a complete packet before building a prettier queue. It also means testing a refusal, a missing field, and an attempted shortcut—not just the easy inquiry. Release is a decision supported by evidence, not a consequence of the agent saying the work is finished.
How does a real failure become a rule or test?
The documented improvement rule is to turn each real failure into a finding plus a rule or regression test, then review the fix before adopting it. Local evaluation findings include proposed rules and regression checks. Existing tests also cover passing estimate status into the policy decision so closed or paused estimates are handled appropriately.
A finding is not a completed fix. Keep the original scenario, the unwanted behaviour, the proposed correction, and the proof needed to close it. Re-run relevant checks after changing the policy. If the correction only changes wording while leaving the same permission available, ask whether it actually addresses the failure mechanism.
When can routine follow-ups move to Stage 2?
Stage 2 is planned for narrowly defined routine follow-ups only after 30 clean days in Stage 1, further testing, and separate owner authorization. Reaching day 30 alone does not unlock sending. The current proposal-only prototype does not enable autonomous follow-ups, and difficult replies or exceptions still need human review.
Before considering that step, define what “clean” means for the specific workflow and retain the evidence supporting the decision. Agree which message type may run, when it must stop, and how to return to manual handling. The authorization should name that limited routine, not grant broad control over customer communications.
See the estimate follow-up example for proposal-only checks that illustrate approval boundaries and stop conditions.
What does a scoped installation cost?
Setup is $3,500 Founding Client or $5,000 standard, followed by $1,500/mo managed or $5,000/mo Operations Partner. Those figures are not a blanket quote for every integration or a statement that Stage 2 is included. Confirm scope, ongoing responsibilities, and third-party usage before granting access to live tools.
Start with the AI front desk overview and the prompts-to-harness architecture. The practical objective is a reviewable workflow with an accountable owner, not a claim of hands-free operations.
Frequently asked questions
Does the current local harness send messages?
No. It evaluates proposals and returns policy decisions. It does not execute customer-facing actions.
Who approves messages in Stage 1?
The owner or specifically authorized reviewer approves each outbound message before release in the Stage 1 operating model.
Can the agent change its own permissions?
The demonstrated tool interface does not include policy editing. Separate code checks proposed actions against the configured permissions and blocking rules.
Does Stage 2 start automatically after 30 days?
No. It requires 30 clean days, further testing, and separate owner authorization. Autonomous follow-ups are not enabled in the current prototype.
Are proposed fixes already verified?
Not necessarily. A finding and proposed rule still need implementation, review, and evidence that the relevant checks pass.
Design the review before connecting the tools
Bring one repetitive intake task and identify the person responsible for its decisions. We can scope the approval boundary and evidence needed for release. Book a Fit Call.
Evidence reviewed November 7, 2026 (PST): ABH's linked architecture and industry pages, local demonstration policy and runtime, engineering standard, evaluation findings, and fictional worked-example specification. Those materials support design and prototype statements, not completed client deployments.
