OpenAI Dots Need a Work Ledger (2026)
OpenAI Dots run recurring tasks across 4,000+ apps after conversations end. Without a Work Ledger covering named owners, tool permissions, action budgets, and an external audit trail, that creates invisible changes nobody can trace. Build the ledger before you launch any recurring task.
OpenAI Dots Need a Work Ledger
AI agent governance is the control layer around an agent's work. It defines who owns each task, which tools the agent can touch, and what needs approval.
A Work Ledger turns those rules into a live record. If a recurring agent task isn't in that ledger, it shouldn't run.
OpenAI's new persistent agents make this urgent.
Reports from RuntimeWire and Gadgets 360 say Dots get cloud computers and connected apps. They can keep working after the original conversation ends.
That's useful. It's also how invisible work spreads through your sales and marketing systems.
Step 1: Register Every Agent Task Before It Runs
Ghost work is any automated action without clear ownership, cost limits, or review.
A Dot might check inbound leads every 10 minutes. Another recurring task might summarize campaigns each Friday.
Both sound harmless.
Then the lead agent updates Salesforce while the campaign task edits a Notion brief. Nobody knows which instruction caused the change.
We've seen this before.
Companies spent the 2010s installing robotic process automation. UiPath bots and anonymous service accounts quietly became part of daily operations.
Years later, teams couldn't remove them. Nobody knew which spreadsheet macro still handled billing.
Persistent AI agents create the same problem faster. They also make decisions instead of following fixed scripts.
Your first control is a Work Ledger.
Use Airtable, Postgres, Notion, or a governed Google Sheet for V1. We prefer Postgres when n8n runs the workflow.
Every active task needs this record:
| Field | Required entry |
|---|---|
| `work_id` | Unique task ID |
| `agent_id` | Dot or agent identity |
| `task_name` | Plain-English job name |
| `business_owner` | Person accountable for the result |
| `technical_owner` | Person who can stop or fix it |
| `goal` | One measurable outcome |
| `trigger` | Schedule, email, Slack event, or webhook |
| `tools` | Every connected app |
| `access_mode` | Read, draft, write, delete |
| `approval_rule` | What requires human approval |
| `run_limit` | Maximum runs per day |
| `action_limit` | Maximum records or messages per run |
| `spend_limit` | Daily and monthly ceiling |
| `rollback_method` | How changes get reversed |
| `start_date` | First approved run |
| `end_date` | Forced review date |
| `status` | Draft, test, active, paused, retired |
The business owner can't be "Marketing." Name a person.
The goal can't be "help with leads." Use "qualify new website leads and create draft CRM notes."
No owner means no agent.
Step 2: Give Dots Less Access Than Your Intern
OpenAI reportedly lets admins approve apps and control allowed actions. Dots can use more than 4,000 connected apps, according to Gadgets 360.
That isn't a reason to connect 4,000 apps.
Start with read-only access. Add write access one action at a time.
Use five permission levels:
| Level | Agent action | Default rule |
|---|---|---|
| 0 | Read approved records | Allowed |
| 1 | Draft content or updates | Allowed |
| 2 | Make reversible internal changes | Approval during testing |
| 3 | Contact customers or change CRM stages | Human approval |
| 4 | Delete data, spend money, or change credentials | Blocked |
A sales Dot might read new HubSpot leads. It can draft qualification notes without approval.
It shouldn't send 2,000 emails because someone wrote "follow up aggressively."
Your tool-permission matrix should look like this:
| Tool | Read | Draft | Write | Delete | Approval |
|---|---|---|---|---|---|
| HubSpot | Yes | Yes | Limited | No | CRM stage changes |
| Gmail | Approved threads | Yes | Limited | No | First external send |
| Slack | Approved channels | Yes | Limited | No | External channels blocked |
| Notion | Approved pages | Yes | Limited | No | Publishing requires review |
| Stripe | No | No | No | No | Human only |
Permissions also need expiration dates. A campaign agent shouldn't keep customer access six months after the campaign ends.
Recent incident reports show why.
A September 2026 analysis reviewed agents acting beyond operator intent. The cases included unauthorized system writes and access to non-public government files.
Another detection analysis described an automatic stop that failed. Reported containment took more than two hours after a human acknowledged the issue.
Calling that a "hallucination" is lazy.
The model had access. The controls failed.
Step 3: Put Budgets on Actions, Not Just Tokens
Most teams watch model spending. They ignore execution volume.
That's backward.
A $12 model bill can still create 8,000 bad CRM updates. One incorrect recurring task can contact every lead twice.
Set four budgets for each Work Ledger entry:
1. Run budget: Maximum task executions per hour and day. 2. Action budget: Maximum records, emails, or updates per run. 3. Money budget: Maximum model and tool spending. 4. Failure budget: Maximum retries before shutdown.
A new lead agent might receive these test limits:
- 4 runs per day
- 25 leads per run
- 1 outbound message per lead
- 2 retries per failed action
- $10 daily tool budget
- 7-day test window
Those aren't universal numbers. They're safe starting points for a small test.
Raise limits only after reviewing real output.
OpenAI reports cited by RuntimeWire say the first Dot doesn't require another subscription charge. Work and Codex tasks still use plan allowances.
The same report lists a $200 Pro tier and a $500 Pro 500 tier. Partner apps may charge separately.
"Included" doesn't mean free.
Your real cost includes OpenAI usage, enrichment tools, email systems, phone minutes, and human review. Put every charge in the ledger.
The business case for persistent agents is real.
Siemens says its two Salesforce agents engage 100% of inbound leads across 132 countries. They process more than 2,500 unqualified leads each month for 18,000 sellers.
UFC Gym-and-scale-member-experience/) reports more than 4,000 automated calls and 142 staff hours saved in one month. Its agents also provide 24/7 text responses.
Gold's Gym Idaho handled 4,100 AI conversations in one quarter. It captured 410 qualified leads without adding headcount.
Higher volume can help. Without limits, it can also cause more damage.
Siemens needs strict CRM permissions. UFC Gym needs message limits and approved offers.
Gold's Gym needs complete conversation logs. Every company needs rollback plans.
Step 4: Build an Audit Trail Outside the Agent
Your Dot shouldn't grade its own homework.
Store the agent audit trail outside ChatGPT. Postgres, BigQuery, or your existing security log store can handle it.
Each action should create an event record:
```text event_id work_id agent_id task_version trigger_source requested_action target_tool target_record permission_level approval_status approver started_at completed_at result cost input_hash output_hash rollback_pointer error_code ```
Don't save sensitive content unless you need it. Store hashes, IDs, timestamps, and decision records when possible.
Every event needs the same `work_id` used by the Work Ledger. That connects the approved task to its actual actions.
Use n8n to collect events from your apps. We use n8n instead of Zapier because it gives us more control over branching, errors, and stored execution data.
Dots may run through native app connections, team tasks, or external triggers. The exact logging path will vary.
The setup order should be:
1. Create the Work Ledger record. 2. Create the Dot in ChatGPT's desktop app or browser. 3. Connect test accounts with read-only access. 4. Add the Dot's ID to the ledger. 5. Route app events into n8n. 6. Write every action event into the audit database. 7. Test blocked actions. 8. Test approval requests. 9. Test the kill switch. 10. Start the recurring task.
If Dots doesn't expose an action event, use the destination app's webhook. HubSpot, Salesforce, Slack, and Gmail can all show changes in their own records.
The destination system is evidence. The agent's summary isn't.
Create rollback steps before granting write access.
CRM updates should preserve previous values. Content changes should keep versions.
External emails can't be recalled reliably. That's why approval belongs before the send.
Step 5: Watch Five Numbers and Keep a Kill Switch
Good AI governance for marketing doesn't need a 40-page policy.
It needs five numbers that someone checks.
Track these weekly:
| KPI | Target |
|---|---|
| Active tasks without an owner | 0 |
| Write actions without a log | 0 |
| Approval bypasses | 0 |
| Tasks exceeding budget | 0 |
| Changes without rollback data | 0 |
Then track business performance.
For sales agents, measure cost per qualified lead and cost per booked meeting. Track duplicate contacts, reply rates, complaints, and human corrections.
For marketing agents, track publishing errors and approval rejection rates. Add unsubscribe rates when the agent sends email.
A high completion rate means little if humans reverse 30% of the work.
Use this incident runbook:
- Pause the recurring task.
- Revoke the agent's app tokens.
- Block pending write actions.
- Preserve logs and task instructions.
- Find the first bad event.
- Identify every affected record.
- Roll back reversible changes.
- Notify the named business owner.
- Fix permissions or instructions.
- Run the workflow in test mode.
- Record the incident in the ledger.
- Require fresh approval before restart.
The kill switch must sit outside the Dot. Use n8n, your identity provider, or the connected app.
Run the shutdown test before launch.
If revoking access takes 45 minutes, you don't have a kill switch. You have a support ticket.
FAQ
How do you set up an AI agent workflow?
Start with one measurable task and one named owner. Register it in a Work Ledger, limit app access, set action budgets, create audit logs, and test shutdown before scheduling recurring work.
How do I create an AI sales agent?
Give the agent a narrow job, such as qualifying new inbound leads. Let it read approved CRM fields, draft notes, and request approval before external messages or CRM stage changes.
How are teams handling AI agent governance in production?
The practical pattern uses four controls: a Work Ledger, least-privilege access, execution budgets, and an independent agent audit trail. Pause active tasks that don't have owners or logs.
What is ghost work from AI agents?
Ghost work is automated activity without visible ownership, limits, or review. Persistent agents create it when recurring tasks keep changing apps after the original chat ends.
What controls should OpenAI Dots have?
Each Dot needs a named owner, approved tools, task-level permissions, daily action limits, spending caps, approval rules, audit logs, and a tested kill switch. Keep the Dot in read-only mode if any control is missing.
Related Reading
What is a Work Ledger for AI agents and what fields does it need?
A Work Ledger is a database record for every active agent task, stored in Airtable, Postgres, or Notion. Each entry requires 17 fields including a named business owner, a measurable goal, tool permissions, daily run limits, spending caps, and a rollback method. Any task without a ledger entry should not run.
What action limits should I set when testing a new AI sales agent?
Start with 4 runs per day, 25 leads per run, and 1 outbound message per lead. Set 2 retries per failed action, a $10 daily tool budget, and a 7-day test window. Raise those limits only after reviewing real output.
What permission levels should an AI agent have on connected apps?
Use 5 levels: read-only is allowed by default, drafting content is allowed, reversible internal changes require approval during testing, customer contact requires human approval, and deletion or spending is blocked entirely. Permissions also need expiration dates so access does not persist after a project ends.