Basis cut first-day onboarding from two hours to 30 minutes, while Clay saved about an hour a day on inbox cleanup. But what the three companies actually made reusable was not prompts, but the sequence, state, and completion criteria of work.
The secret to 30 minutes is a work specification, not a conversation
The core of the Basis example was not handing onboarding guidance to a chatbot. It was turning a procedure a person had demonstrated once into a skill with trigger conditions, steps, required tools, and completion criteria. On their first day, new hires receive Codex and a company-specific onboarding skill, while the agent explains the company’s core concepts and handles computer integration setup in the background. According to the company case published by OpenAI, this reduced first-day onboarding time from two hours to 30 minutes.
A skill here is not a collection of clever prompts. OpenAI’s product documentation also describes skills as reusable instructions, with organization admins able to manage creation, use, sharing, and installation permissions by role. In other words, for a skill to become an operational asset, you need to define at minimum who owns it, who runs it, and which changes will apply to the next hire.
Basis has not eliminated exceptions, either. When recurring questions or new exceptions arise, HR updates the skill, and people step in for complex questions. The company also says that in its core accounting-agent business, accountants participate at key judgment points after autonomous work and review the output. That suggests its pattern is closer to a structure where machines run repeatable segments and people handle judgment segments than to “lights-out automation.”
Why pasting in onboarding documents is not enough
Documents explain what someone needs to know, while workflows define what to check on which screen and what state marks the work as complete. Instead of “Set up Slack,” write something like “Sign in with the company email → verify membership in the five required channels → verify notification settings → if it fails, send the reason for stopping to the IT owner.” That makes both execution and review possible.
The three companies handed different kinds of ‘work state’ to agents
The difference across these cases is not the department they automated, but the kind of state the agent needs to remember and move forward.
| Company | Work state handed over | Agent output | Decisions retained by people |
|---|---|---|---|
| Basis | An onboarding process with a stable sequence | Explanations and completed integration setup | Exception handling, culture, and support |
| Clay | Continuously changing, account-specific context | Daily updated folders and prioritized actions | Acting with customers after verifying evidence |
| Exa | Progress state of discovered integration opportunities | Tested PRs and announcement drafts | Priorities, commitments, and deployment approval |
Clay gathered deal context scattered across CRM, email, Slack, calls, and presentation materials into account-specific workspaces and dedicated subagents. Each night, the subagents review primary-source materials and update account folders; each morning, a coordinating agent selects priority actions such as answering customer questions or finding gaps in a buying committee. Clay told OpenAI it saves about an hour each night.
What matters in this structure is not a “summary” but state that remains for the next action. Clay’s official Account Agents page also explains that agents choose next actions based on past contacts, deals, calls, and conclusions, then write those conclusions and reasoning back to the account. They select actionable steps only within an admin-approved scope, and work such as CRM updates or owner notifications can be configured with human approval.
Exa goes a step further. It finds integration opportunities in repositories and the developer ecosystem, gathers relevant context, creates PRs, runs tests, and prepares weekly updates and initial announcements. Still, people review the work before an actual deployment, and the team decides which opportunities to invest in and what to promise external partners. Exa’s code search itself is designed to find real code examples from GitHub repositories, documentation, and Stack Overflow by semantic meaning, providing the foundation for this discovery stage.
Performance figures are baselines for your own experiment, not purchase justification
Going from two hours to 30 minutes, or saving about an hour a day, is an interesting starting point, but you should not transfer those figures directly into your company’s ROI. Both figures are results the companies disclosed through OpenAI’s case studies, and those articles do not provide experimental details such as sample size, comparison period, or error rate. So it is safer to treat them as a hypothesis—“let’s measure this metric ourselves”—rather than universal proof of product performance.
The same goes for token usage. According to OpenAI’s Enterprise Signals, the top 10% of companies by AI usage generated 8.3 times more output tokens per active user than typical companies, and in June 2026, Codex accounted for 64% of combined Codex and ChatGPT output tokens among enterprise customers. However, OpenAI also explicitly describes tokens as an imperfect proxy for business value. Longer output alone does not mean processing time, quality, or revenue improved.
The broader the connection scope, the earlier permission design needs to come
Agents that read email, CRM, Slack, and repositories are more useful, but they also broaden the attack surface. OpenAI’s Codex Action security documentation advises treating PR bodies, commit messages, repository instruction files, and even images as untrusted input, and selecting the narrowest file and network permissions needed for the task.
For your first experiment, do not look at speed alone. Track processing time, unattended completion rate, exception rate, human review time, and number of reversions together. If processing time drops but review time and error recovery increase, the work has not disappeared—it has merely moved into a later queue for people.
How to build one operational workflow this week
Select something that happens at least four times a month and whose normal end state can be described in one sentence, such as new-hire account setup, a weekly customer-status roundup, or checking document links. Do not make high-accountability judgments such as hiring decisions or contract approvals your first target.
Write down the input, menus and tools used, output, and failure condition for each step. Do not leave only a screen recording; convert it into a text checklist such as “Create user in Google Workspace Admin → verify login with company email.”
Put the trigger, required materials, permitted tools, completion criteria, evidence it must provide, and points requiring human approval on one page. Set external message sending, payments, deployments, and permission grants to stop for approval by default.
Perform both the existing approach and the agent-based approach, recording start and end times, success or failure, number of interventions, and review time. Do not look only at the average: preserve the longest case and its reason for failure so you can improve the next version.
Do not solve failures with an individual’s prompt tricks; classify them by asking, “Which condition did we miss?” Add an owner and version, make the fix, rerun pre-change failures as regression tests, and then deploy it to the next team.
If you want to go deeper
How AI-native companies turn workflows into operating capability — Source material covering the three workflows at Basis, Clay, and Exa, plus their organizational scaling stages. openai.com
Basis | About — See how Basis divides judgment points between agents and accountants. getbasis.ai
Account Agents by Clay | AI agents for every account — Explains, at the product level, the structure of per-account memory, permitted actions, and observability. clay.com
Code Search — Official documentation for the search capability Exa uses to supply agents with current code and source context. exa.ai
Enterprise Signals — Covers output tokens, the share of agent use, and the limitations of these metrics. openai.com
codex-action/docs/security.md at main · openai/codex-action · GitHub — Covers untrusted inputs and least-privilege principles for repository-based agents. github.com
