You built an agent over the weekend. By Sunday evening, it could research a topic, compare sources, and produce a useful report. You showed a friend. They asked how you did it. A very satisfying weekend.

Now imagine it is six months later.

One source has moved behind a login. A connector has changed. The memory contains a confident conclusion from an article that was later corrected. The report still arrives every morning, beautifully formatted.

The automation is running. You are less certain about the research.

There is a difference between having a child and raising a child. The arrival begins a much longer commitment: nourishment, guidance, boundaries, attention and adjustment as needs change. That ongoing responsibility is the part of the analogy I want us to carry into agent building.

Who raises the thing after the excitement of making it work?

Stewart Brand’s Maintenance: Of Everything offers a useful foundation. His introduction treats monitoring, repair and eventual replacement as parts of taking responsibility for a system throughout its life. (Brand’s introduction)

In New Model, Who Dis?, I explored how a model change can require us to recalibrate the whole agent team. Here, I want to examine the continuing care that makes the system worth relying on between those changes.

Start with the whole system

An agent’s working environment includes its model, the harness that manages its actions, its memory, connected services and the people who judge its results. OpenAI’s Codex illustrates this combination: its harness manages context, tool use and execution boundaries, while applications supply the information and business rules relevant to their work. (Codex architecture)

The job determines what that environment needs. Sales depends on current account information. Product research needs independent customer evidence. Development needs a working test environment. Support needs the policy that applies today. The same model can require a different maintenance plan in each role.

Before the five questions, fair warning: I am going to borrow an analogy from being human. We could use a sailboat or a factory, but nourishment, working hands, judgment and signs of ill health are familiar territory. The analogy describes the complete system around the agent, including its tools and memory. Keep that whole system in view as we examine its habits.

1. What is it eating?

An agent’s diet includes documents, search results, database records, tool responses and its own stored conclusions. The nutritional value depends on what we need it to do. Someone training for a marathon pays attention to whether their diet supports the work. We should be equally interested in whether our agent’s information supports its assignment.

More context does not guarantee better nourishment. Ten summaries of the same customer complaint do not become ten independent pieces of evidence. A sales agent needs accurate account history; a coding agent needs the relevant implementation and constraints. Feed each for its job.

And the food is perishable.

Imagine a support agent retrieving a clear, detailed refund policy that expired three months ago. The current policy lives elsewhere, under a title nobody thought to include in the search index. The agent can reason beautifully from ingredients that should have left the refrigerator.

Know who owns each important source, when it was checked and how a replacement reaches the agent. Give remembered conclusions the same treatment. Preserve their sources and conditions so yesterday’s observation does not silently become permanent policy. Freshness depends on the subject; a historical date and an account balance have different shelf lives.

Some inputs may be toxic. A retrieved page can contain instructions designed to redirect the agent or extract information. Its author has supplied material to examine, not acquired authority over the assistant. Test that boundary and restrict the actions a poisoned input could trigger.

A useful diet supports the goal, keeps the ingredients fresh and leaves the poison out. Dump the entire pantry into the context window and you may end up with food poisoning that has production credentials. Clean up on isle 6 of the data center.

2. What can its working hands sense and change?

“What can it touch?” was my original question. Working hands capture both sensing and acting.

Consider a massage therapist: their hands feel how tissue responds and adjust the pressure. Feeling and doing form a feedback loop.

But agents are not born with hands. The mind and hands usually belong to different systems. Agents borrow theirs from CRMs, browsers and other business tools that humans already operate. We are handing the controls to AI to act on someone’s behalf.

That borrowed authority must fit the task at that moment. Too little access and the agent cannot finish the job. Too much and a sales assistant preparing account briefs can also rewrite the forecast because someone connected a broadly privileged account during the prototype.

Its job description says research. Its credentials have more ambitious career plans.

The feedback loop still matters. Read the customer’s account, make an authorized change, then inspect the resulting state. “Request accepted” may only mean the operation entered a queue.

Make clear whose authority the agent is using. Test that permissions allow the work and block prohibited actions at the tool or service boundary. Record what changed and, where practical, make mistakes reversible.

3. Does it know its job—and its limits?

Suppose a security agent begins by grouping duplicate alerts. Someone adds prioritization. Later, someone lets it close apparently harmless cases. The system has moved from organizing evidence to deciding which evidence a human may never see.

Its mandate, permissions and evaluation need to move together. “Reduce the alert queue” is an incomplete job description if the purpose is to help detect and investigate meaningful events. Closing everything would produce a spectacular dashboard for a very short period.

The job description also needs room for “I don’t know,” “I need more evidence,” and “this decision needs a human.” If every successful run must end with a confident answer, we have made uncertainty difficult to report honestly.

Creativity has a place. A product agent exploring possible features should offer alternatives and label its assumptions. A support agent explaining refund eligibility should establish what the current policy says. Inventing a more satisfying policy would be creative. Finance may use another word.

Ask where imagination is useful and where the task requires faithful application of evidence or rules. Make that distinction explicit. A hypothesis should remain visibly a hypothesis until it is checked; missing evidence should trigger a search, clarification or handoff.

Then inspect actual runs. Does the agent recognize those boundaries? Can it admit uncertainty without being treated as a failure? Knowing when to stop improvising is part of knowing the job.

4. Where is the proof, and will we notice trouble?

An agent says it fixed the bug and ran the tests. Which revision was tested? Did the relevant test execute? Does the original failure now behave correctly? “All tests passed” is less reassuring when no tests were discovered.

Match evidence to the claim. For research, inspect whether sources support the conclusions. For an account change, inspect the resulting record. Preserve enough evidence to revisit the judgment later.

This returns to a first principle I take from Brand’s maintenance argument: sustained care requires attention before a breakdown. Brand explicitly includes close monitoring in maintenance. My application to agents has two parts: make deterioration visible, and build the habit of looking for it. (Maintenance: Of Everything)

The system should expose its condition. Show the last successful source refresh, failed tool calls, skipped checks, unresolved uncertainty and changes in the rate of human corrections. A successful scheduled run with a failed data refresh should clearly identify the stale input. A green indicator that only proves the process started tells the maintainer very little.

Build that inspection rhythm into the system. Automate recurring checks and rerun them after a model, tool or policy change. Use AI to examine completed cases, compare trends and investigate surprises, bringing evidence with its escalations. People review meaningful exceptions and audit a sample of the work, including apparent successes; silent failures will not volunteer for the failure queue.

Even the checker needs checking. Tests age, scoring rules become inappropriate, and two agents can share one unsupported assumption. An alerting system helps, but the absence of an alert is not proof that everything is healthy.

5. Is it worth the Human Cognition Tax?

Imagine a meeting assistant that saves fifteen minutes of note-taking and creates twenty minutes of correction and follow-up. The transcript looks good. The task assignments are wrong often enough that everyone reads them twice.

The automation has successfully relocated the work.

I would call the human attention required to keep an agent useful its Human Cognition Tax. Count supervision, checking, clarification, correction, exception handling and ongoing maintenance. Include the work pushed onto colleagues. A cheap token bill can conceal an expensive demand on people.

As a starting design budget, I propose 80/20: machine-scale work should absorb roughly 80 percent of the effort that previously required people, leaving 20 percent budgeted for human cognition. That human share includes deliberate judgment and the human portion of the inspection loop we just discussed.

To make the proposal measurable, use human time as a practical proxy for cognitive effort:

Human Cognition Tax = ongoing human minutes with the agent ÷ human minutes for a comparable manual workflow.

Suppose a weekly batch of account briefs previously took 100 human minutes. With the agent, people spend 12 minutes reviewing, five handling exceptions and three maintaining the system. The tax is 20 percent. At equivalent scope and quality, the system has absorbed 80 percent of the former human workload.

We are measuring human effort displaced. Counting machine seconds, tokens or tool calls alongside human minutes would not give us a meaningful 80/20 split. Nor should easier assignments or lower-quality results masquerade as improvement.

Why start here? It makes us budget attention instead of assuming reviewers have an unlimited supply. It reserves meaningful room for judgment and oversight. And it makes hidden cleanup visible while there is still time to redesign the workflow. Even a small request for human attention becomes substantial when the agent repeats it thousands of times.

The ratio is a proposed starting point, not a measured law or a claim about every job. Some work needs a larger human share. Choose that deliberately, and keep required review intact. If the system creates more human work than the comparable manual process, treat that as a design failure to investigate: revise its scope, inputs, tools or handoffs. Adding another permanent reviewer should not be the automatic repair.

Track the tax alongside accepted results, defects, reopened work, elapsed time and operating cost. Watch total human hours too; 20 percent of an enormous workload may still exceed the attention available. Budget initial setup separately and include it when judging the overall return. If quality falls or human cleanup rises, the system needs attention even when every scheduled run completes.

Maintenance has to scale too

Give the whole service an accountable owner, and build the capacity to maintain it into the service itself. The same proposed 80/20 budget should apply to maintenance: aim for AI to absorb roughly 80 percent of the effort, with 20 percent reserved for human cognition. Measure that against the human effort the same maintenance would otherwise require.

AI can investigate stale sources, rerun evaluations, group related failures and carry out authorized, reversible repairs with checks on the result. People set the boundaries, judge difficult exceptions and audit whether that maintenance is working. An AI maintainer that forwards every observation to a person has become another inbox.

Even that 20 percent must fit the actual time and attention available. A team with four hours a week for oversight still has four hours after you add another hundred agents. Track total hours, interruptions and decisions waiting for people. If demand exceeds that capacity, improve the automated maintenance, simplify the system or limit its workload until the humans can keep up with the necessary oversight.

Simplicity helps. Every instrument added to a sailboat comes with something to maintain at sea. Can you repair it with the tools and skills available when the fault occurs? Ask the same of every component you add to the agent.

Having the agent begins the responsibility of raising it. As its capacity and capability grow, its ability to help maintain the whole system needs to grow too. The humans do not come with an automatic capacity upgrade.

Mahalo for reading!
Aloha –TK