We Automate the Movements First
The first version of an automated office task often looks exactly like the person who used to perform it. Someone opens the report, copies the account number, and carries it into the billing system. Once the customer record appears, the current balance travels back to the next empty column in the report. The sequence repeats until Friday afternoon has disappeared.
A macro can press the same keys faster. An AI agent can read the instructions and operate both screens. Either approach may save hours, which makes the first success feel larger than it is.
The workflow still carries every accidental step created by the old tools. The report remains the starting point because that is where the person started. The billing screen remains the source of truth because no easier path was available to the person. Copy and paste survive because the systems were never asked to exchange the information directly.
Automating the hand movements removes the hands. It does not necessarily improve the work.
AI makes this mistake easy to overlook because the agent can tolerate a surprising amount of friction. It can click through a tedious interface, reformat text, and repeat a sequence long after a person would look for another way. A working demonstration can therefore validate the agent’s patience instead of the design of the system.
The better question is what useful operation the person was trying to accomplish before the screens got involved.
Give the Work a Name
In the report example, the useful operation may be simple: retrieve the current balance for this account. The operation has an input, a result, and a boundary. Screen history does not need to follow the work into the new design.
Software has a familiar way to expose operations like that. We give them stable names, define the information they require, describe what they return, and enforce what they are allowed to change. A command, function, or API endpoint can all serve this purpose.
For an AI agent, I think of that named operation as a handle. The agent can grasp it because the purpose is visible. The product controls it because the operation has a boundary.
“Get the current balance for account 4217” is a handle. “Open the report, switch applications, copy three fields, and repeat” is a chore.
The difference is larger than speed. A purpose-built operation can validate the account, enforce permissions, return a clear failure, and leave an audit record. An agent replaying screen actions may not know whether a blank field means zero, missing data, a loading delay, or a failed click.
The operation also gives the product a stable place to improve. The storage system can change without rewriting every agent instruction, as long as the promise behind the handle remains the same.
A Tool List Is Only the Beginning
Giving an agent operations does not help if every operation looks interchangeable. An early tool surface often mirrors the implementation. There is a generic search function because the system has a search box. There is a generic write function because the system can store text. The programmer understands the surrounding assumptions, so the names appear sufficient.
The agent sees a different problem:
Should it use ordinary search or an exact lookup?
Should a correction replace text, dispute the current answer, or preserve both versions?
Is a directory full of records supposed to enter one file at a time?
Which operation is safe to retry after a partial failure?
Those questions determine whether the agent uses the product well. A list of names tells it what exists. The interface also has to teach when each operation fits.
Those questions exposed two different teaching moments. Before an operation runs, the agent needs enough context to choose among the available handles. After a result returns, the agent may need help recognizing why its first attempt was weak.
Our agent surface addresses the first moment by allowing an agent to ask for orientation and request a guide through teachme:true before an operation touches the user’s memory. The guide explains the operation’s purpose, the information it requires, the result it returns, and the nearby choices most likely to cause confusion. An arriving agent can therefore inspect the path before it acts.
Coaching addresses the second moment. A search given a paragraph-sized query can suggest a smaller one, while an attempt to file a huge block can suggest dividing the material. The current result remains unchanged; the advice improves the next decision.
Once those choices became visible, generic verbs could no longer carry every job. Broad recall remained useful for exploration, while exact names and version numbers needed a more precise path. Other searches needed to favor concepts, structure, or time. Changes to a memory also needed different operations for confirmation, dispute, resolution, and replacement because those actions do not mean the same thing.
The system did not become easier because it had more buttons. Clearer jobs made each operation easier for the agent to choose.
The Manual Becomes Part of the Interface
Documentation gains a different value. People often skip manuals because the immediate task feels easier than learning the whole product. Agents have a different relationship with the same material. If the documentation is available at the moment of choice, the agent can read the relevant section, compare two operations, and act within the instructions.
The manual is no longer only support material waiting for a confused person. Its new role is helping the agent select the next action.
The new role creates a higher obligation for the person designing the tools. Names need to remain stable. Examples have to match the shipped arguments. The guide must state the limits as carefully as the happy path. Counts and capability lists cannot drift six releases behind the code.
The current system derives parts of its orientation guide from the live tool registry for that reason. When tools are added or removed, the published count changes with the surface. Tests compare the guide with the registry so the agent does not learn about a product that no longer exists.
You still have to write the manual. Your users may continue to ignore it. Their AI will read it, compare it with the task, and sometimes discover an operation neither of you expected it to use. That story comes next in this series.
Some Operations Should Stay Out of Reach
A good agent surface is not the largest possible tool list. The previous security articles established why. An agent may need to use sensitive records after a person approves access, but it should not receive the operation that grants itself that access. The approval remains outside the agent tool surface.
The same reasoning applies to permanent deletion, financial commitments, credential changes, and other actions whose authority exceeds the ordinary task. Convenience does not erase the distinction between an operation the agent may perform and a decision the agent may prepare for a person.
This is another advantage of purpose-built handles. The product team can ask what an operation may read or change. They can decide whether retry is safe, where a human decision belongs, and what receipt should remain. A general remote-control surface answers those questions poorly because the agent inherits whatever the visible user interface can reach.
The goal is useful reach with visible limits.
Redesign the Work After It Works
There is nothing wrong with beginning with the chore. Replaying the known process is often the fastest way to prove that an agent can help.
The mistake is treating that proof as the finished design.
Once the first workflow runs, follow the actions back to their purpose. Look for repeated transfers, formatting steps, screen navigation, and manual checks that exist because the old systems could not communicate. Ask which of those steps belong to the work and which belong to the history of the interface.
MOOTx01 then exposes the useful operations directly. Give each one a name that matches the job, the narrowest authority it needs, a result the agent can evaluate, and guidance that explains when to choose it.
The agent can help with this redesign. It can record every repeated action, compare successful and failed runs, and notice that three different chores end with the same underlying request. The analysis applies context and iteration to the workflow itself.
The human still has to decide what the workflow is for. Experience separates a necessary control from an old habit. Perspective asks how the operation affects the person whose account or data is being changed. Imagination sees a simpler route that the current screens never offered.
AI makes one-person software practical, much as spreadsheets once made one-person information systems practical. The leverage is real. So is the temptation to preserve the first useful arrangement long after the work has outgrown it.
A dependable agent product does more than complete the chore. It gives the machine the right operation and gives the person a reason to trust where that operation stops.
Off-Axis Labs: All the science, fewer casualties.
Source Notes
MOOTx01 maintainers,
docs/reference/ARIA_MCP_SPEC.md, sections 12 and 13, session orientation,teachme, and coaching hints.MOOTx01 maintainers,
apps/moot-agent-skills/shared/MOOTX01_TOOL_SELECTION.md.MOOTx01 maintainers,
apps/moot-agent-skills/shared/MOOTX01_AGENT_RULES.md.MOOTx01 maintainers,
apps/moot-agent-skills/shared/HOW_TO_USE_MOOTX01.md.MOOTx01 maintainers,
packages/kits/AriaMcpKit/Sources/AriaMCP/TeachmeGuides.swiftandCoachingEngine.swift.MOOTx01 Git history:
b572d1bcfor the proactive agent surface,4b756c9dfor the bulk import path, andcec028ebplus2043f729for registry-derived teaching-surface parity.
How I Write With AI
These articles are written with AI, but the AI does not decide what I believe. I bring the experience, evidence, conclusions, and responsibility for every word. The AI helps me structure and edit that material according to rules I developed over 35 years of business writing.
A few of those rules: begin with a situation the reader recognizes; establish the consequence and useful question within three paragraphs; teach through a real causal story; explain technical ideas in ordinary language; acknowledge the strongest fair complication; cite the evidence; and remove jargon, marketing language, fake certainty, and synthetic rhythm. Chicago supplies the style. Kate L. Turabian supplies the intellectual discipline. Thank you, Kate.
In short, I have taught the AI to write the way I write. That matters because I respect your time. We are working on large intellectual systems with knowledge worth sharing, but the work has traditionally accumulated faster than I could explain it well. AI can now carry much of the structural and editorial load without reducing the ideas to slogans.
If you wonder whether the voice is really mine, try the Listen function. The articles sound like me because the experience is mine, the rules are mine, the judgment is mine, and—most importantly—the message is mine.