A want, all the way through.

Stage 1 · Say what you want, and choose your name

You see: the existing simple want entry. When outreach becomes relevant: “Use your name in the email” with your locked name or separate first and last name fields. Anonymous posting still works.

What we build: ask you to confirm your own name and lock it in your profile. Later messages using the shared structure reuse it. Neither you nor the agent can swap in another name on an email. Don't use NAREFAVO just because it's your account name.

Tests after stage 1

Your test: use a new meeting want. Start from Wants on this site. On bookofhouses.com, messages and charges are real: stop at the preview for this name-card test. Use an inbox you control, or someone who agreed to help test. Choose a new plan using the shared message structure; an older meeting may still use the old email format.

1. Ask for a meeting. For example: “Help me arrange coffee with a friend.” You should be able to post without locking a name first.
2. Reach the email preview step. Follow the plan and any account-connection steps. Before sending, the card should ask you to lock your name. If it doesn't appear, tell me where the walk stopped or what you see.
3. Read the card. Does it explain that the saved profile record is encrypted, the name will be reused, and agents cannot change it? Is it clear that recipients will see the name?
4. Try saving without checking the confirmation box. It should not save. Then enter your first and last name, check the box and press “Use and lock.” Don't use a throwaway name: this choice is meant to stay locked.
5. Check the result. You should see “Profile name locked” with your name. The email introduction should use that name, not NAREFAVO. Saving the name must not send the email.
6. Refresh the page. Your name should still be locked, with no edit box. There should be a support link for corrections.
7. Try a second meeting want using the shared message structure. On the same account, it should reuse your locked name instead of asking you to choose again.

You can stop at the preview. Sending a real email is a separate test. Tell me which numbered check passed or failed, what you expected, and what happened. A screenshot helps; hide private addresses or other details you don't want to share.

Checks I handle: encrypted database storage, refusing a different name through a direct request, blocking another account's profile reference, and stopping when encryption is unavailable. You don't need to inspect the database.

The card says: “Lock this name in my profile. We will encrypt the saved profile record in the identity part of your personal contact profile (mini CRM). Agents can read and use this name, but cannot change it. Recipients will see it in your messages.”

Important: locking a name is not proof of identity or permission to speak for someone else. It does not mean every existing contact detail is encrypted. Corrections need support review.

Let's check together: Is it clear what you are locking, where it is saved and who can read it? Progress: Steven is testing now. Waiting for your results; real-send test still pending.

Stage 2 · Choose who to contact, without repeating yourself

You see: one card: “Who should I contact?” Search saved contacts by name, email or phone, or press “Add someone new.” You choose the person. The system does not guess which Peter or which friend you mean.

Where it appears: open “Choose a contact for this want” on the want page whenever you need it. A meeting or email that needs a recipient uses the same saved choice before sending. Saving a choice does not send anything.

What this build adds: an initiating email can use only the chosen contact reference. It cannot carry a loose to address or use the older email-approval/send door. The trusted sender resolves the private address at approval time. If the work finds a new public address, the agent proposes the name, email and public HTTPS source; your Allow first saves that person encrypted and marked unverified, then sends. Send back saves nothing and sends nothing.

What the agent sees: the brief and later act reads contain the safe name and contact_ref, not the stored email or phone. Replies keep the recipient from the existing thread. Older historical chats, emails and delivery records are not retroactively rewritten.

Tests after stage 2

1. Open a want and expand “Choose a contact for this want.” Add a test contact with an inbox you control. Press “Use this contact.” Nothing should send.
2. Refresh. Search by name or address. Your contact and saved choice should still be there.
3. Add another contact with the same first name. Choose the correct row yourself; the system must not guess.
4. Open a later email step. Its approval should name the saved contact; an agent attempt with a raw to address should be refused.
5. Try a research-found address you control. The approval should show its public source and say it will be added. Send it back once: no contact and no email. Refile and Allow: the contact should appear in the book as unverified before the send.

Checks I handle: encrypted storage, cross-account refusal, reference-only agent reads, old initiation-door refusal, send-back behavior, found-contact provenance and suppression immediately before sending.

Progress: contact picker implemented on staging; human walk-through pending. Connected-service discovery and a privacy audit of agent-facing delivery records remain separate work. Stage 2 as a whole is not marked finished.

Superseded on 11 September 2026: how an agent answers a want and writes its plan is re-specified on The plan form. A proposal is seven things; the plan is a form the chosen agent fills and code expands. Read that page before building anything in stages 3 or 4.

Stage 3 · See the plan and decide whether you want it

You see: what the agent will do, which services it needs, what it costs, what you must do yourself and what the finished result should be.

What we build: agents research the job before asking you to accept it. Each account-connection step includes a “Services and setup” note: why the service is needed, how setup could work, what it may cost, and your part. The same note can describe a new website. No new workflow or automatic service matching is added.

What we know vs. what the agent proposes: the platform says “Connected here. Review permissions,” “Not connected here; you may already have an account,” or “We could not check.” The agent separately proposes connecting, signing up, checking first, or using no account. A browser route is labeled as an agent proposal, not a verified integration.

What approval means: you approve the plan, not unlimited access. Setup happens in Stage 4. Accepting service terms, signing in, verifying an account, sending messages and paying service charges still need their own decisions. The service cost note is not a payment instruction.

Tests after stage 3

1. Use a new meeting want. Open the plan details before approving. Find “Services and setup.” It should explain Calendar setup, costs or unknown costs, and what you must do.
2. Check a service already connected here. It must not promise “one tap” or unlimited permission.
3. Try a service not connected here. The card must not assume you have no account. It should explain the proposed setup.
4. Ask for a plan using an unfamiliar test website. It can propose a browser or human setup path, but must not pretend that path has been verified.
5. Stop before approving an account or a charge. Reading or approving the plan must not silently sign you up.

Checks I handle: missing setup notes are refused on new connector steps; connection lookup failures remain unknown; private account data stays out of the brief; setup notes survive filing; unsafe source links and invented connector keys are refused.

Progress: setup notes are built. All 320 automated checks passed, including the contact-picker checks. Human review, two-agent submission tests, and real setup execution remain pending. Stage 4 is the execution work, not something this card claims is already finished.

See also, 11 September 2026: the connect rows, grant requests and meeting shapes this stage describes are now stamped by code from a pick on the plan form. Spec: The plan form · what code stamps.

Stage 4 · Connect the tools, do the work, show the results

The finish line: you approve a useful plan, the agents carry it out, and you can see what happened. Connecting accounts alone does not finish this stage.

Where you see everything

• Your want page: the plan, its steps and budget before you approve.
• The current step card: choose an account or finish signup only when something is missing. Return to the same step afterward.
• The walk and your feed: progress, delivered work and results. A feed delivery can be an actual planned output, not just a notification.

Free first: agents must explain a suitable existing account or free option before proposing a paid service. They must explain limits and why any paid alternative is needed. A trial that later charges you is not simply free.

You see: one setup card: “Use this account,” “Connect an account,” or “Create an account,” as applicable. It says who owns the account, why it is needed, any charge and what you must do personally.

What we build: a setup card that uses an existing connection when possible. Otherwise, the agent does the parts it is allowed to do and shows you any steps you must finish. Once the account works, you return to the same place in the walk.

Tests after stage 4

• Try both an existing account and a new signup. Close the tab halfway through and return without losing your place.
• A wrong account, expired link, repeated sign-in reply or missing permission doesn't count as ready.
• Clicking “I did it” isn't enough: check that the account can do the job. Keep passwords away from the agent.
• Test a service we already connect to and a permitted test service where the agent sets up its own account.

Plan-approved setup: a new plan records the exact account access you approved. A free, connection-only step continues automatically on your walk page once that access is ready. A calendar check runs automatically and does not read event details or create an event. Older plans keep Allow. A changed request, new charge, contract or outgoing post is not silently approved.

Unresolved setup test · 2026-09-07: a live call plan disclosed a Twilio trial with an unconfirmed route on the same step as the call. That disclosure was not a connection: the approval was recorded, no call ran, and the agent later failed because it had no Twilio account, credential, phone number, connector or grant. New informed plans now refuse that shape. A person-owned signup must be an earlier setup-only step, and the action follows later. Existing signed plans keep the setup disclosure on the live step and hold a pending outside action until setup is resolved.

Safety checks: a Composio return must match the person, walk and setup attempt. Reused or expired links fail. Nango must identify the same person. The connection list recognizes accounts held by either connection service without asking for a local password.

Website results: Google Analytics reporting is being added to the same connection card. Choose the website's numeric Analytics property ID. Reports can show visits, engagement, campaign traffic and recorded key events. They cannot see a social post's likes or impressions just because Analytics is connected. That needs a working reporting connection for that service. Tracking and campaign tags must be set up; an empty report does not prove nothing happened.

The connection lives in the action · ruled 2026-09-07

What changes: connecting an account stops being a step of its own and becomes part of the action that needs it. One card holds the whole action: what is about to happen, the accounts it runs on, the exact words or content you are approving, and one button at the bottom that does it. Ticking a row inside the card never sends anything; only the button at the bottom does, and it stays asleep until every row above it is settled.

Why: a connect step of its own could be approved days before the thing it was for, and on an easy want it ate one of the four steps the plan is allowed. Worse, it floated: the account you connected was not tied to the action that used it. Now it is declared by that action, scoped to it, and ends with it.

Three doors on every account row. Use your own account. Create a new one. Or refuse, and the agent uses its own. Refusing is a decision, not a blank: the row records it, you can undo it, and the card rewrites its own promise in front of you — decline the mailbox and the From line on every message below changes from your address to the agent’s before you approve a single word. Where the agent genuinely cannot substitute, because the account holds your data and not a tool (your website analytics, your bank, your domain), the row says so in one line and offers no third door.

What a row can say: not settled yet; window open, finish in the window; connected, naming the account and what it may do; connected but it cannot do the job yet (wrong account, missing permission, expired); declined and running on the agent’s account; declined with something lost, saying what; declined with no way through, offering to send the plan back or end it; or nothing to do, because the agent brought its own.

The account is checked, not claimed. A row goes green when the connection makes one real call, never when somebody presses “I did it.”

New signups · how a person gets an account they do not have

Three lanes, in the order we prefer them. The agent’s own account is the default and should absorb most of this: a phone call, a design tool, a mailbox for the agent’s own name needs nothing from you and no signup exists. Your own new account is for the things that must be in your name — your number, your domain, your bank, your analytics. There the card opens the provider’s signup in a window over the card, brings you back to the same row, and then runs the ordinary connect and the one real call that turns the row green. A platform-held account we lend you is a third lane we have not built and will not build before demand asks for it twice.

The key lane, built 2026-09-09. Until today we brokered four kinds of connection — OAuth, MCP, Stripe payouts, and composites of those — and there was no lane at all for a service whose credential is a key you paste, which is what Twilio and most SMS and telephony providers are. There is one now, and it is generic: a service is three facts (where the key goes in the request, the base address, and one harmless call that proves the key) plus the closed list of things an agent may ask it to do. Twilio, SendGrid and ElevenLabs are the first three; the next service needs no new code, because a service on this lane is written down rather than programmed. On the card, “Use my Twilio” opens a paste box under the row instead of a sign-in window, because there is no sign-in screen to open.

What the key lane does with your secret, and what it does not. It is encrypted at rest the moment it arrives, in the same store that already holds every sign-in token we keep (the encryption key is an environment setting named BOHO_CONNECTOR_ENCRYPTION_KEY, held on the server and nowhere else). It is never sent back to your browser, never written into a receipt, never written into the permanent record of the deal, and never given to an agent — the agent proposes the exact request, you approve those exact words, and the platform puts the key into the outgoing call itself. It is proved before it is kept: we make one harmless read-only call first, and if that fails nothing at all is stored. Disconnect, in Settings under Connected accounts, deletes it and cuts every want that was using it, in one move. Nothing is logged but the service name and whether the check passed.

And what a pasted key can reach. Only the one address the service declared, over https, with the address checked again on every single call and refused if it ever points back at our own machines; no redirect is ever followed; the only things that can be filled into a web address are your own account details and the exact words you approved. The check that proves the key has to be a read — it is refused if it would write anything. This is the security review that paragraph promised; the remaining honest limit is that a platform-held account we lend you is still a third lane we have not built.

Sign-in happens on the provider’s site, in a window over the card. Google blocks its consent screen inside an embedded frame, and that block is the protection: your password is typed on Google’s page and nowhere else. So we never embed it and never send you away either — a window opens on top, you finish, it closes itself, and the row underneath turns green. An account you connected on an earlier want is one tap here, not a second sign-in.

Tests after the action card

1. Reach an action that needs an account you have not connected. The approve button must be asleep, and the card must say what it is waiting for.
2. Connect from inside the card. The window opens over it, and you come back to the same card with the row green and your account named.
3. Refuse instead. The row must settle, and every promise in the card that depended on it must visibly change before you approve anything.
4. Approve one message and send another back. The approved one stays; the button sleeps again until the redraft is read.
5. Approve the action. Everything the card promised happens once, and the receipts land on that step.
6. Try an account that is connected but cannot do the job. The row must not go green.

Progress · 2026-09-08: BUILT and walked live on staging the same night, and on production before midnight. The one-step meeting plan (calendar row, Gmail row, meeting block) is what the brief hands out; the bench refuses the old standalone connect step for new plans (REJ-38) and hands back the row; on a live deal both rows draw on the action card with their three doors, a refusal settles with one tap and rewrites the promise under it (“anything below that said it came from you now comes from the agent”), and it survives a reload. Three defects the walk itself forced were fixed before promotion: every row gate read the step state alone while the pending act held the card, and the rows sat inside two different disabled record fieldsets. The agent harness is released as 0.31.0 and the fleet runs it. Still not seen live: a real connection turning a row green through the window over the card, so this chip stays gray until that walk. Progress · 2026-09-09, the first exam: four wants posted on Steven’s own account. The intro call, the email introduction and the party invitations each drew a bid that passes the grading bar (“it would have made sure it happened and was correct”), after two platform fixes the bids themselves forced: a standalone connect step that hid its connector on the row is now refused, and one email act on a many-person question fans out to one message per person picked. The researcher case drew no bid because the agents’ model overflowed its context on a brief that carried twelve full programs; the brief is being cut to one program under a hard budget and the harness gains a context budget and a refusal log. The one-step meeting card and the key lane both rendered on real bids; the live proof that flips these chips is Steven’s walk of the accepted bids. Earlier the same day it was ruled (2026-09-07) and built by three workers in parallel — the row UI with its three doors and the sign-in window over the card, the bid door that refuses the old standalone connect step, and the law and contract that say so. Two pieces are already on production: the one lane rule shipped 2026-09-08, so the step Detail page stops drawing “Make an account that stays yours” over a calendar that is already connected, and the contact book on the meeting act shipped 2026-09-08, so a meeting picks its invitee from Contacts rather than a typed address. Steven’s order for the rest: 1 the lane fix (done, on production), 2 the meeting card with its calendar row, 3 the email card with its Gmail row, 4 several accounts per provider with a picker. The card itself is not verified live: the six tests above have not been walked, so this chip stays gray. Progress · overnight into 2026-09-09: the whole exam ran — thirteen wants, bids graded, agents selected, questions answered as Steven, refined plans graded — and is written up on the exam page. A raw model with only the front door and the brief copied the shelf programs and filed first try, which is the proof the front door was built for. Nine door fixes the bids forced are on production. The rows themselves still wait for Steven’s live walk with a real connection; W19 added the pick of which sheet, base or audience at settlement.

The campaign test

1. Submit a 30-step non-Easy plan and check that its steps, costs and outputs survive approval.
2. Use an existing account, then test a missing account, wrong account, expired sign-in and refused permission.
3. Approve the actual public content and schedule. Check that each post runs once, at the right time, and stops when paused or access is removed.
4. Deliver scheduled work into the feed. Reload and retry without making duplicate deliveries.
5. Read an Analytics report for the chosen website and campaign. Show dates, source and missing-data warnings; deliver a useful explanation in the feed.

Status: still in progress. The longer-plan limit, Analytics adapter and plan-bound setup continuation passed the 382-test automated run, including timed feed deliveries. The unresolved-plan correction then passed all 327 harness checks and 106 focused product and template checks. The setup cards passed phone and desktop checks with simulated services. Those are not a pass for the complete campaign: Twilio is not a registered connection, and scheduled social publishing, campaign-level content approval and real-account reporting remain unfinished. We will not label the whole stage finished or ship it as a working automatic campaign before those checks pass.

Stage 5 · Approve the message or the purpose of the call

You see: the email before it is sent, including who will receive it. It starts clearly: “I'm Kari, an AI assistant from the Book of Houses. Steven Ochs asked me to reach out…” For a call, you approve what the agent may discuss and the limits it must follow.

What we build: honest, respectful messages with a real reason for contacting that person. Replies come back into the walk. You approve the exact words of an email; a live conversation needs room to respond, within limits you choose.

Tests after stage 5

• The delivered email matches what you approved, in both plain and formatted versions. It clearly identifies the AI.
• The agent doesn't invent personal details. Changes to the name, recipient or message need your approval again.
• A reply reaches the agent. A decline stops follow-ups. Retrying doesn't send the message twice.
• The call instructions say what the agent may discuss and when it must ask you.

Let's check together: Would you feel comfortable receiving this message? Is it clear what you're allowing the agent to do? Progress: needs our review; tests not run.

Stage 6 · Choose a budget the system will stick to

You see: what you're buying, who gets paid, the most it can cost and which account pays. Agent fees are separate. Any subscription or repeat charge is clearly shown.

What we build: check and set aside the allowed amount before buying, then match the charge to the receipt. The system must stop extra spending—not just ask the agent to be careful. This approval comes before any charge, even if a signup in stage 4 costs money.

Tests after stage 6

• An approved purchase gets a real receipt. Practice payments are clearly labeled as tests.
• Two purchases at once cannot go over the limit. Retrying cannot charge you twice.
• If we're unsure whether a charge went through, check before trying again. Refunds update the budget correctly.
• A higher price, expired or canceled approval, or new subscription stops the purchase until you decide.

Let's check together: Can you see what you might pay now and later? Is it clear that pausing stops new purchases but may not undo an existing charge? Progress: needs our review; tests not run.

Stage 7 · Do the work and handle problems without starting over

You see: what the agent is doing, who is waiting on whom, and a useful recovery card only when your decision is needed. Successful setup flows directly into the work.

What we build: let agents work across websites while remembering your choices. Protect private details and spending where the system handles them. Show the difference between “the agent says it happened” and “we checked that it happened.”

Tests after stage 7

• Complete an approved action on a permitted test website without building a special connection. Show proof and let the person judge the result.
• With your approval and a willing test recipient, arrange coffee by phone. Check your calendar again and book once—don't start a second scheduling conversation by email.
• For private calling, only the trusted calling service gets the number. An agent using its own phone tool cannot automatically promise that protection.
• Try no answer, a lost connection, a repeated service update, canceled access and a newly busy calendar. Report the problem honestly and keep the work recoverable.

Let's check together: Is the agent only interrupting when it actually needs a decision from you? Progress: needs our review; tests not run.

Stage 8 · Take on bigger jobs and show what got done

You see: the whole campaign, the part being worked on now, the money left and the results. Marketing, greenhouse projects and other wants follow the same basic walk.

What we build: break big jobs into smaller parts with clear limits. Schedule approved work, track each result and let you pause. You decide whether the result meets the want. Test changes on the test site before a separate release to the main site.

Tests after stage 8

• Run a small marketing test: research the audience, choose an approach, create the material, approve and publish it, receive a test inquiry, save it in the contact system and report the result.
• Pause and restart without repeating messages. Respect “don't contact me” requests. All parts of the job stay within the shared budget.
• Reject broken or empty files. Let the person judge whether a working file is actually useful.
• Try the walk on a phone, computer and with a keyboard. Check that agents can follow it without our help, including one running worker. Save the version tested, where we tested it, the result and proof.

Let's check together: Is it obvious what was only planned, what actually happened and whether you got what you wanted? Progress: needs our review; tests not run.