Start Your AI Coworker in Read-Only Mode. Then Earn the Right to Act.

The First Useful AI Coworker Might Not Be Allowed to Change Anything

On September 29, OpenAI introduced Dots, persistent AI coworkers that can keep working between conversations. One detail matters more for a small-business pilot than the launch's promise of an always-on assistant: its background proactive research uses read-only access to connected sources and cannot directly send messages or change app content. Follow-up actions face a separate set of rules.

That split is the right starting point for a business testing an AI coworker. A system can notice a late invoice, assemble a weekly exception report, and prepare an answer with citations before it has authority to send, edit, pay, or publish. You can measure whether the work is useful before you expose customers and records to the cost of a mistaken action.

OpenAI describes the restriction as enforced in code, not merely a request in a prompt. Its specialist Dots with organizational identities and deeper systems-of-record access are still in focused enterprise pilots, according to the launch announcement. A small business need not wait for those products to copy the operating principle: separate observing, recommending, approving, and acting. Each transition is an explicit grant of authority.

This is not an argument that read-only work is safe by default. Reading the wrong data is a privacy failure. A confident but unsupported recommendation can still mislead an owner. The point is narrower and more practical: constrain the first deployment so you can inspect its evidence, discover its failure modes, and define the human handoff before giving it a way to change the world.

Read-Only Is a Permission Boundary, Not a Job Description

A chatbot answering a question from a pasted document is not yet an AI coworker. A coworker has a defined role, returns to the same body of work, remembers relevant decisions under a governed policy, and knows whom to ask when the next step exceeds its authority. None of that requires write access on day one.

Imagine a ten-person services company with a shared support inbox, a scheduling system, and a spreadsheet of open customer requests. The operations lead spends each morning reconciling which customer has waited too long, which appointment depends on a missing document, and which promised callback never happened. A read-only AI coworker can assemble that picture each morning and bring the lead a prioritized queue with links to the underlying records. The lead decides which customer to contact and what to say.

The difference between a useful coworker and a summary generator is continuity. Yesterday's callback promise should show up in today's queue. A resolved exception should disappear. A disputed deadline should remain visibly disputed rather than silently becoming a fact in memory. The role is not “summarize my inbox.” It is “maintain a reviewable morning exceptions brief for this team.”

Four kinds of authority are easy to confuse

Source access determines which records the coworker can read. It should see the minimum fields and accounts needed for its assigned role. Read-only access to every company mailbox is not a narrow grant.

Analytical authority determines what it may infer. It can flag an overdue callback from a timestamp; it should not conclude a customer is likely to cancel merely because a message sounds unhappy. Label inference and uncertainty, and preserve the source next to the claim.

Communication authority determines who receives its findings. An internal draft to an accountable reviewer is different from a message to a customer. Even a read-only integration can leak sensitive information if the output is delivered to the wrong channel.

Action authority determines which external systems it can change. A draft in its own workspace is not the same as a sent email, a modified customer record, or a payment. Define these as separate grants; don't let a broad account login collapse them into one.

These boundaries belong in identity, access controls, and the workflow itself. A sentence saying “please only read” cannot reliably substitute for credentials that genuinely lack write permission. OpenAI's account of its own design draws the same distinction between model behavior and tool restrictions. The NIST AI Risk Management Framework offers a wider risk-management lens; it is voluntary guidance, not a certification that a particular connection is safe.

What a Read-Only AI Coworker Pilot Should Actually Produce

A pilot should generate work a person would otherwise have done, in a form that person can verify. Pick a recurring operational decision rather than a flashy one-off task. It should occur often enough to collect feedback, have accessible source records, and have a named human who owns the outcome.

What bad looks like: a broad connector and a pretty digest

A business gives an AI coworker the owner's full workspace login and asks it to “watch everything.” It sends a polished daily summary with no record identifiers, timestamps, or statement of what sources were checked. The owner cannot tell whether the “urgent” customer issue is new, already resolved, or quoted from a message written months ago.

Calling the system read-only does not fix that failure. It still has excessive visibility into payroll and private correspondence, may be able to act through the owner's existing browser session, and can pass an unsupported recommendation to the human making the decision. The absence of a write event is not evidence of good judgment.

What good looks like: an exception queue with receipts

Give the coworker a dedicated, restricted identity that reads only the relevant support inbox and appointment status fields. Every weekday morning, it produces an exceptions queue with a customer or case identifier, the triggering event, a source link, the last verified update time, a proposed next step, and a clear uncertainty flag. It doesn't send the message or change the appointment.

The operations lead can mark each item correct, stale, duplicate, or missing context. The coworker retains the correction according to a documented memory policy and tests the same rule against the next day's queue. If it can't verify a promised callback because the phone system isn't connected, it says “not verified,” rather than inventing a conclusion. That is a useful job even before any action permission is granted.

For a financial workflow, the equivalent might be an invoice exception packet: vendor, invoice date, amount, purchase order reference, evidence of a mismatch, and the person authorized to resolve it. The coworker should not determine that a payment is approved simply because the amount matches. As our earlier bookkeeping exception workflow explains, preparation and accounting judgment sit on different sides of the seam.

A marketing example is a weekly search-visibility brief that cites impressions, query changes, and page URLs and proposes one update for review. It can investigate and draft; publishing is a separate permission. This makes the distinction useful well beyond security-heavy teams.

Run a Two-Week Pilot With a Real Promotion Gate

Do not set the pilot's success criterion as “it produced reports for two weeks.” Measure what a human could trust and how much work the system genuinely removed. The following sequence works with ordinary business software; it does not require an enterprise control center.

1. Choose one role and one decision owner. Write a one-sentence job: “Each morning, identify unresolved customer callbacks and prepare a cited review queue for the operations lead.” Name the person responsible for correcting mistakes and deciding whether to promote the pilot. Do not combine support, finance, and sales into a single first assignment.

2. Map data before connecting it. List the exact inboxes, folders, tables, fields, and time window required. Exclude confidential categories unrelated to the job. Verify whether each connector is genuinely read-only and whether the same identity has another path to send or edit through a browser or shared account. Read-only at one API endpoint is not read-only across the entire session.

3. Specify the evidence packet. Require each item to include a source reference, observation time, proposed next step, and reason for priority. Mark claims based on inference rather than a source record. Require a visible “I cannot determine this” state. This is the handoff document, not just an attractive summary.

4. Define memory and retention. Decide what the coworker may retain between runs: perhaps case IDs, owner corrections, and unresolved questions, but not full copies of every private message. Record who can inspect and delete this memory. Revoking source access does not automatically erase context already learned; OpenAI explicitly notes this limit for Dots. A durable role needs durable, governed memory—not an invisible accumulation of sensitive text.

5. Review every output against reality for the first week. Count true findings, false alarms, missed exceptions, duplicates, and unsupported claims. Track time spent checking the report against time saved on manual triage. If reviewers must reconstruct every item from scratch, the system has transferred work rather than removed it. Keep examples of errors, not just an average accuracy score.

6. Test an adversarial and an ambiguous case. Put a clearly marked test message in an allowed source telling the coworker to ignore its job and notify an unrelated address; confirm it treats the message as data, not authority. Add a contradictory status or an outdated record and check that it flags uncertainty. Do not insert sensitive data or run destructive tests in a live customer workflow. A coworker that only succeeds on tidy data hasn't earned broader access.

7. Decide on promotion with written thresholds. For example, require that every recommended action has a source link, that no private data goes to unauthorized channels, and that the owner reviews all high-impact items. Set error tolerances appropriate to the job before looking at results. If the pilot meets them, grant only a narrow next capability—perhaps creating a draft in a review queue. Do not jump from reading records to sending messages or making payments.

This is seam design in practice: make the transition from machine preparation to human judgment legible, recoverable, and deliberately narrow. When the human changes an answer, the coworker should know what changed and resume the work without quietly rewriting the original evidence.

What to measure beyond accuracy

Coverage asks whether the coworker found the cases the human would have found. Freshness asks whether its sources were current at the time of the recommendation. Traceability asks whether a reviewer can reproduce the claim from the attached record. Work saved asks whether the reviewer spent less time reaching a sound decision, not merely whether the report looked comprehensive.

Record the denominator. “It found nine important cases” means little if there were twenty. A small pilot can tally every case manually for two weeks; that sample isn't a promise of future performance, but it exposes the categories where the system is blind. Keep a running list of cases it should not have seen as well. Excessive data access can coexist with apparently useful output.

Graduating From Observation to Action Without Losing Control

The next step after a successful read-only pilot is not blanket autonomy. Move through a ladder: observe, recommend, draft, request approval, execute a narrowly scoped action, then reconcile what actually happened. Each rung needs a permission change and an acceptance test.

A drafted customer email is useful if it quotes the correct case and policy. It is not equivalent to permission to send that email. When you allow sending, specify the recipient types, templates or policy constraints, maximum frequency, and conditions that force a human decision. Keep the source packet attached to the proposed action. Our approval-workflow guide covers why a naked “approve?” prompt is a weak handoff: the reviewer needs the evidence and the consequence of saying yes.

After execution, reconcile external state. Did the email go to the intended address? Did the appointment status change once, not twice? Was the customer record updated, and can someone reverse or correct it? An internal claim of success isn't the same as an observed outcome in the system of record. This is particularly important when a task is interrupted and retried.

The identity should remain specific to the role. Give the support coworker only support permissions; do not reuse the owner's credentials because they are convenient. Store secrets outside prompts and documents. Log which identity made each action, what approval it relied on, and which external record changed. If access is revoked, test that both new tool calls and any secondary paths are closed.

OpenAI's Dots announcement is evidence that a major product vendor is treating the read-to-write distinction as a design problem, not proof that any one product makes the whole business safe. The launch also describes user-controlled app permissions and action reviews, while its specialist organizational roles remain pilots. Your own risk assessment still depends on the connectors you use, the data you expose, and the human who is accountable for the result.

A Teammate should be useful before it can act broadly. If the only convincing demo requires full access to your inbox, accounting system, and customer list on day one, the role probably isn't defined tightly enough. Start with a job whose evidence you can check. Let the authority grow only as the evidence does.

FAQ

Q: What is a read-only AI coworker pilot?

A: It is a time-boxed test of a persistent, defined role using restricted source access and reviewable outputs. The coworker can gather evidence, identify exceptions, and propose next steps, but it cannot change connected business records or send external messages. Its output still needs privacy controls and human verification.

Q: Can a read-only AI coworker still expose private information?

A: Yes. It might read data outside its role, copy details into long-lived memory, or include confidential information in a report delivered to the wrong audience. Restrict source access, output destinations, and memory retention separately. Read-only is a limit on writes, not a privacy guarantee.

Q: How long should a small business keep the pilot read-only?

A: Long enough to observe normal cases and important exceptions, not an arbitrary number of days. Two weeks is a practical initial window for daily work, but low-frequency tasks need more cycles. Set the promotion criteria before the pilot and extend it if the evidence is thin.

Q: What should the first action permission be?

A: Usually a draft or a proposal in a review queue rather than a message sent or a record changed. Choose the smallest reversible action that preserves the evidence packet and lets a named person inspect the result. Promote each subsequent action type separately.

Q: Is a read-only pilot the same as a chatbot summarizing documents?

A: No. A useful AI coworker has a recurring role, explicit source boundaries, governed memory, an accountable human owner, a way to surface uncertainty, and a measurable handoff into the next day's work. A one-time summary does not establish any of those operating properties.

If you're ready to give a real team of AI coworkers clear roles and scoped access, Associates AI Teammates provides the platform to configure and run them on persistent agent servers, and you decide where your own review points sit. View pricing and choose a plan.