You delegated the work—so why are you still explaining and checking everything?
Even when you hand recurring weekly work to AI, if the person in charge still has to explain the context and recheck the results, the worker has changed but the operating model has not. As prompts grow longer and automations multiply, it also becomes harder to find where exceptions occurred.
Basis, Clay, and Exa tackled this problem in different ways. They turned work with stable sequences into reusable skills, kept continuously changing context in account-specific workspaces, and added testing and human review to execution that produces external results. What all three companies turned into operating assets was not conversation scripts, but work state and evidence of completion.
Basis turned onboarding explanations into ‘completable procedures’
Basis did not merely reduce the time spent giving new hires information. It turned a process demonstrated once by a person into company-specific skills with triggers, execution steps, required tools, and completion criteria. On day one, new hires receive Codex and onboarding skills, while the agent explains the company’s key concepts and proceeds with computer integration setup. In a case study OpenAI published in September 2026, Basis said first-day onboarding time fell from two hours to 30 minutes.
That figure is still a single case reported by Basis. The sample size, measurement period, configuration error rate, and HR review time were not disclosed, so it does not mean every company can save 75%. What is worth taking from it is not the number but the design that connects explanations to real state changes.
Documents and execution procedures end at different points.
A document saying “Set up required collaboration tools” ends once it has been read and understood. An execution procedure needs completion evidence and exception handling, such as “Confirm the approved services list → sign in with the company email → record participation status for required channels → stop if an account conflict or additional permission request occurs.”
Exceptions do not disappear, either. In the Basis case, HR updates skills when recurring questions and new exceptions emerge, while people step in for complex questions. Given that Basis also says accountants participate at key decision points and review completed outputs in its accounting agent, the company’s operating principle is closer to separating repeatable execution from expert judgment than to unattended automation.
Clay created state that remains the next day, not just summaries
For work that changes daily, such as deal information, fixed procedures alone are not enough. Clay brought deal context scattered across CRM, email, Slack, calls, and presentation materials into account-specific workspaces. Dedicated subagents review source material each night to update account folders, and a coordination agent selects priority actions in the morning, such as answering customer questions or identifying gaps in the buying committee. Clay reported saving about one hour previously spent sorting its inbox every night.
The key is that yesterday’s conclusion becomes today’s input. Clay’s Account Agents product page also describes a structure in which agents choose the next step from permitted actions based on previous interactions, deals, calls, and conclusions, then record conclusions and reasoning back to the account. CRM and data warehouse records are presented as subject to human approval. However, public information does not establish whether this commercial product and the internal Clay system in the OpenAI case study are implemented identically.
Exa connected discovery all the way to tested PRs
For work that affects code and external partners, the validation path matters as much as producing the output. Exa’s Codex workflow monitors the developer ecosystem for integration opportunities, gathers relevant context, creates PRs, and runs tests. It also prepares weekly updates and, when needed, draft initial announcements, but people review before actual deployment. The team decides which opportunities to invest in and what to promise external partners.
Separately, Exa provides Code Search, which indexes GitHub repositories, documentation, and Stack Overflow to connect natural-language queries with real code examples. However, the public case study does not say that this product was used directly in the internal integration workflow. It is therefore more accurate to treat Code Search as a separate product for addressing code discovery, rather than conclusively calling it the technical foundation of the Exa case.
| Nature of the work | Closest example | Operating asset to retain | Where people decide |
|---|---|---|---|
| Sequence and normal completion are stable | Basis | A skill with triggers, steps, tools, and completion criteria | New exceptions and complex questions |
| Customer- and account-specific context keeps changing | Clay | A persistent workspace that accumulates source material and conclusions | What action to take with the customer after verifying evidence |
| Produces external results such as PRs, sends, or deployments | Exa | Test results and reviewable outputs | Priorities, external commitments, and deployment approval |
A first-pilot design checklist to complete before execution
Public materials do not provide a path for installing or running Basis’s company-specific onboarding skills. The procedure below is therefore not a guide to a particular product; it is a design checklist for confirming with the responsible owner that you are ready to run a pilot. OpenAI likewise recommends starting by defining the owner, baseline, KPIs, and guardrails, then specifying triggers and permissions, evidence of completion, and handoff points for people.
- Choose one task with a record of current execution. You should be able to describe its normal completion state in one sentence. Record current processing time, exceptions, number of human interventions, and review time as your baseline.
- Choose a structure that fits the work state. If the sequence is stable, use a reusable skill; if information keeps changing, use a persistent workspace; if it produces external results, classify it as constrained execution with testing and review.
- Write triggers and permitted scope in concrete language. For example: “Start when the start date and company email are confirmed. Read only the approved account list and verify setup status. Stop if a permission-grant request, account conflict, or service outside the list is found.”
- Define completion evidence and human stop points first. For new-hire account setup, the owner must be able to verify source records such as login-confirmation records for every required service; for code changes, test results and change details. Separate external sends, data edits, deployments, and permission grants as items requiring approval.
- Confirm the owner and environment to use before execution. In one table, list the product name and supported plan, installation or access path, person responsible for login and authentication, systems to connect, minimum permissions to grant, where work input is placed, and where results and audit records are checked. If even one of these is undecided, you are not yet at the execution stage. If you choose GitHub’s codex-action, treat PR bodies, commit messages, repository instruction files, and images as untrusted input, and select the narrowest file and network permissions.
- Set rules for feeding exceptions into the next version. Record pilot failures as a missing condition, insufficient context, incorrect permission, or review-rule issue, and decide who will modify and re-review the skill, workspace, or tests.
Criteria for readiness to run a pilot
The task owner, current baseline, product and access path to use, authentication and connection owner, input location, minimum permissions, location for checking completion evidence, and approval owner must all be determined. If any are missing, do not guess execution commands; consult the product’s official installation and authentication documentation, then create a separate execution procedure.
Success is not output volume.
In June 2026, Codex accounted for 64% of combined Codex and ChatGPT output tokens among enterprise customers, and the top 10% of companies by monthly AI use produced 8.3 times more output tokens per active user than companies in the middle range. But OpenAI also explicitly notes that token volume is an imperfect proxy for business value. After beginning an actual pilot, compare metrics suited to the work—completed work, cycle time, quality, exceptions, review load, cost, and risk—against a baseline recorded in advance.
How skills are shared and managed also needs to be confirmed for each product. ChatGPT skills can package instructions, examples, and code for reuse and sharing, and Enterprise and Edu administrators can manage related permissions by role. However, official help documentation also notes that availability, installation, synchronization, and governance may differ in other products. Do not assume these management screens and permissions apply to Codex in the same way.
What to copy from the three cases is boundaries, not numbers
Basis’s 30 minutes and Clay’s one hour per day show what may be possible, but they are not controlled experimental results with publicly disclosed samples and comparison methods. The first thing our teams should determine is not just “How much faster did it get?” but how far the agent executes, what it retains as state, and where people take responsibility.
Add completion criteria to stable procedures, persistent context to changing work, and testing and approval gates to execution that creates external impact. You also need to finalize the product and access path, permissions, and input and result locations before moving into a real pilot. Once these boundaries are clear, AI automation moves beyond one person’s long prompt and becomes an operating workflow that the next person can repeat and improve.
If you want to go deeper
How AI-native companies turn workflows into operating capability — A source piece for examining Basis, Clay, and Exa workflows alongside criteria for writing agent job descriptions. openai.com
Account Agents by Clay | AI agents for every account — See at the product level how account-specific memory, permitted actions, human approval, and observability connect. clay.com
Enterprise signals: What frontier firms are doing differently — Learn why tokens are an imperfect proxy for business value alongside enterprise AI usage figures. openai.com
codex-action security guidance — Explains concretely how GitHub-based agents should handle untrusted input and least privilege. github.com
