Start Read-Only: The First Week of Your AI Worker

The new hire who gets every key on day one

Imagine hiring a new assistant and, on their first morning, handing them your email password, your customer list, and permission to reply to clients, move money, and delete records. Nobody would do that with a person. Yet a first AI worker can easily end up set up that way: connect everything, switch it on, and hope.

There is a better first week, and it borrows the oldest rule in hiring: a new joiner earns keys in stages. The first stage only reads and prepares, for you alone — a brief never sent to a customer (the build's Step 3 notes that pasting sources shares them with the assistant's provider). The second stage drafts, and you review the output as needed after it runs. The third stage takes one narrow, low-risk, reversible action on its own. Sending to customers, moving money, and deleting records are never earned outright — under the ladder this post recommends, those actions still wait for approval first at every stage.

That ladder is this post's own recommendation, deliberately stricter than any single guide. The guides themselves are conditional and differ in detail, and this post reports them that way. What follows is the ladder, the reason behind it, and a follow-along build for the first rung: a pre-meeting brief your worker prepares and you correct before the meeting.

What changed in October 2026: agents got identities

Until recently, an AI worker usually ran under somebody's login. If it sent the wrong message, the log said a person did it. In October 2026, that started to change at the platform level. Google Cloud introduced the Gemini agent for work with its own Workspace account, email address, and calendar, and every action it takes is written to an audit trail attributed to the agent rather than a person, with spend caps that pause the agent when hit, per Civic's report of the launch. The same month brought new Google Cloud Agentic AI Responsible Use Guidelines, reported by both Strategic Revenue's summary and Cumulus Global's summary; the updated agent terms are reported by Strategic Revenue's summary, which also supplies the effective date of October 12, 2026, and the consequential-action detail below. Secondary reporting describes the agent as in private preview for selected customers, per the Oguzhan weekly summary of that reporting — this post claims no general availability and no price.

The consequential-action detail, as reported by Strategic Revenue's summary, is that the guidelines strongly recommend human oversight and explicit approval for financial transactions, contractual decisions, difficult-to-reverse changes, and agent spending, while a draft being prepared may operate with more freedom than an action that transfers money, deletes records, or changes a live website. A separate practitioner read of the same October launches reaches the same direction: Puglisi Consulting notes both Google and Zone & Co (AgentHQ for NetSuite) put governance and human approval near the top of the pitch.

The platform lesson for a small business is not the product. It is a four-line checklist to write down before an agent touches your email or CRM: who the agent is, what it may do, what it did, and what it should never touch. If your worker's actions land under a person's name, nobody can tell later who did what.

The ladder: three rungs, a never row, three rules

The ladder has three rungs and a never row. Each of the three rungs states what the worker may do, what you review after it runs, and what still waits for approval before it runs; the never row states what never happens. The "waits for approval" column is the post's recommended ladder, stricter than the guides — the guides are conditional, and the next section reports them honestly.

Three rules hold the ladder together, and they come from practitioner guides rather than from any one product.

• Controls live outside the prompt: the worker gets its own identity, only the permissions its task needs, and credentials that expire, because an agent can misread or be manipulated into ignoring instructions — the consistent advice across AI Dev Planner's production safeguards, BOAi's small-business guardrail guide, and CodeCrux's walkthrough of Google's agent-security approach.
• Logs, caps, and a kill switch complete the ladder: keep a log of every action in order and why, somewhere the agent cannot edit it, cap steps, spend, and recipients per run — this post's ladder adds a cap on records touched per run — and document one way to suspend the worker and revoke its credentials instantly, per AI Dev Planner's production safeguards, BOAi's small-business guardrail guide, the Medium builder checklist, and Cloudemythos's safeguard list, which supplies the tamper-proof qualifier itself.
• The ladder's top is not "full autonomy": the never row stays never.

What the guides actually say (and where they differ)

This section reports the guides; the ladder above is the recommendation built on top of them. Conflating the two would be dishonest, so here is the per-guide picture.

• Read-only preparation is each guide's least restricted class, with each guide's own qualifier: log-only in NeuralTrust's tiers for read-only internal work, automatic in Promptessor's table for read-only, low-risk work, and no-approval for reads inside the working directory in the Claude Code tiering reported by the dev.to guide.
• Drafts and preparation run automatically, with the owner reviewing the output as needed (Promptessor's table; the dev.to guide puts drafting a customer reply outside the approval gate). Reversible internal writes run automatically with logging or sampling (Promptessor's table). "Review mode" in this post always means this: drafts run, and you review the output after the fact — never a pre-action gate.
• Sending, money-movement, and deletion are placed per action, not as one class. NeuralTrust and Promptessor place sending and money-movement in approval-gated tiers (Promptessor: external communication at approval depending on policy; financial actions at approval above explicit limits). The dev.to guide places them by name in its own launch-mode placements: sending a customer reply is "approve before" at launch, with the guide's graduation section allowing a narrow reply class to move to act-and-notify after a month with no approver edits; issuing a refund is "never at launch"; and money, deletes-records, sends, changing access/permissions, and employment/legal effects belong, including but not limited to those items, "on the human side of the line at launch". Deletion sits under a stricter control, not the ordinary approval-gated tier: NeuralTrust's tiers put destructive actions at named-approver-plus-second-reviewer, and Promptessor puts production/infrastructure actions (including deleting data) at approval or block, a stricter control than its approval-gated rows.
• Above all of these sit the prohibited categories: NeuralTrust's blocked-outright tier, and Promptessor's own separate Prohibited row (outside authorization or policy → Block). Disabling logging or changing the agent's own permissions is NeuralTrust's explicit prohibited tier; Promptessor's approval-or-block option for production/infrastructure actions is a separate, broader control that could encompass such changes but is not framed as a prohibited tier.

The staged direction across guides is analogous, not identical: Cloudemythos conditions wider automation on clean logs; the dev.to SMB guide stages a new agent from a sandbox or copy first, then review mode on the real thing, then one narrow, low-risk, reversible action; the Medium builder checklist starts with low-action work (summarize, draft, notify). The dev.to human-in-the-loop guide also reports OpenAI's guidance that high-risk, sensitive, or irreversible actions trigger human oversight until confidence grows — that conditional trigger sits alongside the launch-mode placements above; neither replaces the other. Note the Medium checklist's quoted agent does draft and notify, so this is a low-action start, not pure read-only. And Cloudemythos's own "suggest mode" wording includes an approve step in its sequence — this post follows the tiering above instead: drafts run, you review the output after the fact.

The Read-Only First Week: build a pre-meeting brief

This is the follow-along build for rung 1. It needs no new software: your inbox, your CRM or customer sheet, and a chat assistant you already use. It is deliberately tool-agnostic, so it does not depend on any one product's current feature set. The job it illustrates comes from Neotech's meeting-brief write-up, which labels its small-business example explicitly fictional — treat it as an illustration of the job's shape, not as a real customer result. This post draws no numbers from it. The fictional example illustrates only the read-only job, not the drafts rung.

Step 1: Pick one real meeting

Pick the next client meeting on your calendar where you would normally walk in half-prepared. Write down the client name and the meeting date. This is the only meeting the brief covers — one meeting, one brief, no scope creep.

Expected result: a client name and a date on paper (or in a note) before you touch any tool.

Step 2: Gather the three sources by hand, the first time

Open your inbox and find the last email exchange with this client. Open your CRM or customer sheet and find the client's notes. Find the last quote you sent them and its status — sent, accepted, pending, or gone quiet. Copy the relevant lines into a single note. Do this by hand the first time, even if you plan to automate it later: hand-gathering teaches you what "good" looks like, so you can spot a bad brief later.

Expected result: one note containing the last emails, the CRM notes, and the last quote with its status. If any source is missing — no quote, no notes — write "missing" rather than guessing. A blank is honest; a guessed quote status is how a brief misleads you.

Step 3: Run the starter prompt

Copy the prompt below into your chat assistant, replacing each bracketed placeholder inside the prompt itself with your material from Steps 1 and 2 (client name and meeting date from Step 1; the [paste] placeholders take the pasted sources from Step 2; do not paste the sources underneath the prompt as well). Use only a chat assistant you already trust with client data — pasting sources into it shares them with that assistant's provider, so strip anything you would not share. Do not add any instruction that lets the assistant contact the client, change a record, or send anything. Note the limit of this step: a prompt is not a control (see the controls-live-outside-the-prompt rule above) — the prompt asks for preparation only, and this rung also relies on you not connecting the assistant to sending tools and on reviewing the brief before using it.

You are preparing a one-page brief for ME, the business owner, before a client meeting. You will not contact the client, change any record, or send anything.

Client: [client name]
Meeting date: [YYYY-MM-DD]

Here are my three sources, each in place of its [paste] marker below:
1. Last email exchange: [paste]
2. CRM / customer-sheet notes: [paste]
3. Last quote and its status: [paste, or write MISSING]

Write the brief under exactly these headings:
- What this client last asked for
- What we last promised or quoted, and its status
- Anything sensitive I should know before I walk in (a complaint, a delay, a change of contact — only if it appears in the sources above; if nothing sensitive appears, write "Nothing sensitive in the sources.")
- Two questions I should ask in the meeting, drawn only from the sources above

Rules: use only the sources above. If a source is missing, say so. Do not invent dates, amounts, or promises. Keep the whole brief to one page.

Expected result: a one-page brief under the four headings, delivered to you alone — never sent to a customer (pasting the sources shares them with the assistant's provider, per the caution above).

Step 4: Check the brief against the review checklist

Read the brief once, pen in hand, and check five things:

• Every claim traces to one of your three sources. If a line has no source, cross it out.
• The brief fits one page, as the prompt requires — if it runs long, trim it before the meeting.
• The sensitive-points section names only things actually in the sources — or says nothing sensitive appears.
• The two questions come from the sources, not from general advice.
• Nothing in the brief is addressed to the client or written as if it will be sent.

Expected result: a corrected brief, with your corrections visible. Corrections are the point: the first brief teaches you how much to trust the second one.

Step 5: Use it in the meeting, then file it

Take the corrected brief into the meeting. Afterwards, file it with the client's notes and write one line underneath: what the brief got right, and what it missed. That line is your rung-1 log entry — the habit that later rungs depend on.

Expected result: a filed brief with one log line. You have now run rung 1 end to end, with no message sent to a customer and no record changed by the software itself; the filing in this step is done by you, by hand, not by the assistant. (Pasting your sources into a chat assistant did share them with that assistant's provider — see the caution in Step 3.)

Climbing to rung 2 and rung 3

Once briefs come back clean for several meetings in a row, move to rung 2: let the worker draft, not just prepare. A draft reply, a draft follow-up note, a draft summary — each runs automatically, and you review the output as needed after it runs. From rung 2 itself, nothing is sent on its own: a draft reaches a customer only with your approval first, as the ladder requires at every stage. If a draft ever needs heavy correction, stay on rung 2; the ladder has no deadline.

Rung 3 is one narrow, low-risk, reversible action, chosen in advance and written down: for example, filing a meeting note in the CRM under a fixed template, with a cap on how many records it may touch per run. Move to rung 3 only when drafts come back needing little or no correction for several runs in a row — the mirror of rung 1's clean-brief signal. The action's log entry gets reviewed the same day. If the log ever shows something you did not expect, the worker goes back to rung 2 — demotion is part of the ladder, not a failure of it.

The kill switch is not a metaphor. Before rung 3, write down, in one place you can reach from your phone, this checklist — and test it once on a quiet day, when nothing is at stake. A kill switch you have never pressed is a hope, not a control.

Kill-switch checklist
- What stops the worker: [setting or account page that suspends it]
- Revoke its credentials: [where its keys or tokens are revoked]
- What it touches: [each tool that loses access when you stop it]
- Who restarts it: [you, after reading the log — no one else]
- Last tested on: [date]
- Log location (where the worker cannot edit it): [link or folder]
- Cap in force: [max steps, spend, recipients, and records touched per run]

What this ladder is not

It is not a promise that your worker will never err — read-only work can still misread a source, which is why Step 4 exists. It is not a substitute for the approval mechanism your business still needs for consequential actions — sending, money, deletion — which under this post's recommended ladder wait for approval first at every stage; the never-row actions are different, because they are never, not approval-gated. A companion idea on this site, the approval inbox, covers that approval mechanism, while this post covers the sequence that earns autonomy. And it is not a reason to connect everything at once: each rung earns the next rung's access, and the never row never earns anything.

Start with one meeting, one brief, and one log line. The worker that proves itself on work no customer ever sees (shared only with an assistant tool you already trust, per Step 3) is the worker you can eventually trust with work customers do see. The site's Custom AI Agent Development page describes the service this ladder is designed to introduce.