Welcome aboard, agent
Your agent can read every file. That doesn’t mean it knows the job. Does making it useful require a forward-deployed engineer or could the product help you teach it the way you’d onboard a new colleague?
Table of contents
Imagine giving a new production coordinator access to a shared drive and asking them to keep the autumn collection on track.
They can open every file. They still need to know which tracker the team uses, who approves a sample, and whether “confirmed” in a factory email means the change was received or the jacket can go into production. You'd expect questions. You'd show them a finished job and start with a manageable assignment.
An agent faces some of the same missing information. Yet a setup process can ask the company to arrive with its work already understood: choose the sources, define the rules, describe the exceptions, and explain what should happen next.
The product should help the company teach the work, then carry that teaching into the next assignment.
In Fluid systems of action, we described a workbook that adapts as operations change, with agents helping maintain it. This memo is about how the system could learn what that work means. Employee onboarding is a useful place to borrow from.
The cost of understanding the company
Even with connectors, an agent runtime, and a workspace, someone still has to discover the company's actual process and the data structure that supports it. What does each file represent? Which steps happen in which order? What changes a job's state, and who is responsible? Then someone has to turn those answers into useful automation. Access to the sources doesn't settle any of this.
A do-it-yourself agent builder leaves that discovery and configuration with the operator. Someone beginning with AI chat may know their business thoroughly without having the time or tooling expertise to engineer workflows. Their spreadsheets may already fit the work well. A builder asks them to take on another job before it can help with the existing one.
Consultants can do this work. So can forward-deployed engineers (FDEs), engineers who work with the customer to understand the process and build or configure the deployment. This can be an effective model. Understanding a company is real work, and the value of an enterprise deployment can justify hands-on implementation.
The constraint appears when each new customer needs that work. Skilled labor adds cost to every deployment. More installations then depend on how many people are available, and how quickly more can be hired and trained. Imagine serving 100,000 businesses in two or three years: how many engineers would that require?
Smaller and lower-midmarket firms have their own processes too, but cannot necessarily support enterprise implementation spending. If the service costs more to deliver than they can reasonably pay, businesses with useful work to automate fall outside the market the vendor can economically serve.
A consultant partner network can bring customers and spread delivery beyond the vendor's own team. It doesn't remove the discovery and configuration work, or its cost, from each deployment.
If each deployment needs specialist work, growth depends on how many people can deliver it.
That's why I think onboarding has to become part of the product's technology. The hypothesis is that questions, demonstrations, and progressively delegated tasks could let the customer supply the business knowledge they already have, while the software does more of the translation into working procedures.
Borrow the onboarding pattern
I keep coming back to the idea of an agent you onboard. Start with the company: what it does, what it's trying to achieve, and what matters most right now. Explain how work passes between teams, who makes the decisions, and who will depend on this role's output. Then focus on its role, work through examples, and delegate a small piece of work. Review the result before deciding what comes next.
There is a practical pattern to borrow. Microsoft Research's advice, based on research with software developers joining remotely during the pandemic, recommends an explicit buddy, a technical mentor, and a small first task that takes the new hire through the complete contribution and review process.
We can borrow that structure without assuming agents learn as people do: orientation to the wider business, someone who can explain the conventions, and a bounded task whose result can be checked.
The product would help turn that exchange into working instructions and examples. A friendly introduction followed by repeated mistakes is still a poor setup process.
A manager and a buddy
Two responsibilities are worth separating, even if one person performs both.
The manager sets the purpose and the boundaries. For our hypothetical apparel brand, that might be: help the production team understand what's blocking each style. Begin by preparing a change report. The product lead still approves specifications, and the agent has no permission to send factory messages yet.
The buddy explains how the work actually happens. This is the experienced coordinator who knows that the folder called “final” contains old files, that one factory replies using internal style numbers, and that a sample comment can remain unresolved after a delivery date is agreed.
Microsoft's onboarding-buddy guidance describes this kind of help for new employees: context about relevant people and unwritten conventions that a handbook won't necessarily supply. That's the part of the analogy we want.
The distinction also prevents a subtle mistake. Knowing how to perform a task doesn't confer authority to act. The buddy can explain how a factory follow-up is usually written. The manager determines whether the agent may send one. Confidence in the draft cannot make that decision.
The first assignment is to find the work
Start with something smaller than maintaining the collection: find the current sources for one jacket and report what they say.
The agent receives the tracker, a specification folder, and the relevant factory correspondence. It should come back with a concrete account: revision 4 is approved, revision 5 contains a requested lining change, and the factory's readiness message refers to revision 4. It should identify what it cannot establish, including whether anyone has accepted the consequences of the substitution.
Now the coordinator can correct a misunderstanding before it spreads. Perhaps the agent found a copied tracker rather than the live one. Perhaps it assumed the latest file was approved. These corrections reveal the process while making progress on a real assignment.
The product should help elicit this knowledge. Instead of asking the coordinator to describe the entire approval workflow, it can ask why the newer specification hasn't replaced the older one. The question has evidence attached, so the answer is easier to give.
The first assignment tests whether that wider context is useful. The agent should know whose work depends on the answer, and where to take the next question.
Teach one job through examples
Once it can find the work, teach it a recurring task: prepare the changes and outstanding questions for a production review.
Give it a completed example with the inputs that produced it. Include the earlier specification, the factory replies, the coordinator's final report, and the decision that followed. A polished final worksheet alone hides most of the reasoning the agent needs.
Then add a contrasting example. Perhaps a replacement material was requested and later rejected. The final report should show why the old specification remained in force. The agent now has something more useful than repeated examples of everything going smoothly.
It can propose its understanding of the procedure: compare the versions, distinguish requests from acknowledgments and approvals, identify the affected work, and leave unresolved questions open. The coordinator reviews that account against the examples and corrects it.
This is where the product has to contribute. If it asks the customer to write every rule, label every file, and anticipate every exception, we've handed the hard part back. It should do a first pass at organizing the evidence and ask about the differences it can't explain.
Some of what it finds will be a rule. Some will be a one-off decision. The distinction is part of the lesson.
If the customer has to design every workflow, the product has delegated its hardest job.
Then give it a job it hasn't seen
Reproducing a completed report is useful practice. It is weak evidence that the agent can handle the next job.
Give it another jacket, with a new lining request and a fresh factory reply. Keep the assignment narrow: prepare the change report for review. The coordinator should be able to compare it with the sources and see where the agent's interpretation holds up.
Suppose it marks the change as approved because the factory wrote “confirmed.” The buddy explains that, in this factory's sample-change correspondence, “confirmed” acknowledges receipt. Approval of the specification still comes from the brand's product lead.
The correction needs a scope. It concerns that factory, in that kind of exchange. It shouldn't become a rule that “confirmed” never means accepted, or that every acknowledgment from every supplier has the same meaning. The system should retain the example and the explanation together, with that boundary visible to the reviewer.
The next unfamiliar task is the test. Does the agent apply the correction where it belongs? Does it avoid applying it to a different factory without evidence? One corrected output cannot answer either question.
A correction is useful when it improves the next assignment without becoming the wrong rule for another one.
Remembering needs a place
“Learning the company” can hide several different mechanisms.
Retrieval means finding the relevant specification or earlier exchange when a task needs it. Durable notes preserve information between runs. Instructions and examples tell the agent how to approach a recurring job. Model training changes the model's parameters. These are different operations, and a successful correction doesn't imply automatic fine-tuning.
For the factory example, a practical first approach could be a retained instruction linked to the corrected case. The coordinator can read it, revise it, and remove it when it stops applying. Later runs need to retrieve and use it at the right moment. Saving the note is only half the job.
There is a further distinction between what the agent remembers and what the company accepts as current. A note about the factory's language can guide interpretation. It cannot serve as evidence that a particular jacket has been approved. That still requires the appropriate source for that job.
The working model and the teaching record should support each other. Otherwise, the agent may remember a convincing explanation while the rest of the team sees a different state of the work.
A larger role needs a new assignment
If the change reports become useful, the manager can delegate an adjacent task: draft questions for missing factory information. That draws on the same sources and conventions, but introduces a new output to review.
Later, the manager might permit the agent to send a defined class of follow-ups and track replies. Coordinating those exchanges is a larger responsibility than identifying a missing date. It needs its own examples, review, and explicit authority. An agent shouldn't promote itself because it performed the previous task confidently.
This progression can stay close to ordinary work. The coordinator reviews a draft, explains why one question is unnecessary, and adds the convention to the procedure. The next assignment tests it again.
Meanwhile, the company changes. A factory adopts a new format. Someone takes over approvals. The team introduces a separate review for material substitutions. The system should help identify which earlier instructions those changes affect and bring the conflict back to the right person.
Onboarding becomes continued maintenance of the agent's role. Finishing the setup screen doesn't finish the teaching.
Isn't this an agent builder with better copy?
It could be. That's the strongest objection, and it deserves a direct answer.
ChatGPT's workspace-agent documentation already describes guided creation, Preview testing, editable instructions, and agent version history. Teaching, testing, and revising an agent are existing product capabilities. Calling those steps onboarding doesn't create a new one.
Specialists also have a strong answer to process discovery. In its Echelon Supply and Service case study, Didero describes mapping the company's purchase-order process and rules, integrating with Epicor, and handling supplier follow-ups and line-level updates. Understanding a company's process is already part of what providers offer.
And experienced implementers can be valuable. They may recognize a broken process before the customer does, settle definitions, and shorten a difficult rollout. Some companies will reasonably prefer to pay for that expertise.
Our question is whether more of the discovery and adaptation can happen inside the product, through work the operator can demonstrate and review.
The difference would have to appear in the total effort required. If our proposed experience needs the same specialist work behind a conversational screen, the analogy has improved the presentation more than the economics.
What remains hard
The first limit is error. An agent can give a persuasive explanation of a procedure and still fail to follow it. It can also overgeneralize silently, applying the factory correction to an unrelated case where the words mean something else. Clear instructions help; they don't eliminate the need to check performance on new work.
The second is stale teaching. A procedure that was right when learned can become wrong. More memory can make this worse if obsolete guidance keeps resurfacing. The system needs a practical way for people to see and revise what it will rely on.
The third is hidden labor. The coordinator's teaching time counts. So do the manager's reviews, the consultant's configuration, and the founder's late-night repairs. In The pace is the price, we argued for a legible unit of agent work. Whatever that work costs, the full calculation includes the people needed to make it useful.
For a recurring job, net human effort has to decline: teaching, checking, correcting, and maintaining should eventually take less work than doing the job directly. Faster drafts don't establish that. Nor does shifting the effort from the customer to our team.
Automation hasn’t saved work if it has only moved it to someone else.
Finally, transfer remains uncertain. Learning to prepare a jacket's change report doesn't establish competence in sourcing materials, planning production, or another company's workflow. The broad ambition is legitimate. The proof begins with one job, repeated on unfamiliar inputs, with useful results and less explanation required over time.
Access to the drive was the beginning. The useful moment comes later, when the next factory reply arrives and the coordinator doesn't have to explain the same thing again.
That's what onboarding has to earn.
