We have traditionally drawn a clean line between managing people and operating software. People receive goals, context, tools, feedback, and incentives. Software receives inputs and produces outputs.
AI agents are making that line less useful.
On a growing range of bounded, digital tasks, an agent can already perform at or above the level of a capable human. That does not make an agent a person, and it does not give a model human judgment or accountability. It does mean that the practical problem is changing. Once software can interpret a goal, choose actions, use tools, and revise its own work, getting a good result looks less like calling a function and more like managing a worker.
The comparison is imperfect, but it gives us a useful framework for building better agent systems.
Onboarding becomes context engineering
Imagine hiring someone, giving them a one-sentence assignment, and expecting excellent work without explaining the company, the customer, the standards, or the decisions that came before them. Their failure would not be surprising. We would call it poor onboarding.
Agents have the same practical need for preparation. They need to know what the organization does, what matters for the task, what constraints apply, what good work looks like, and where the sources of truth live. Supplying and maintaining that working knowledge is context engineering.
Good context is more than a large pile of documents. It is the right information, available at the right moment, in a form the agent can use. A new employee does not become more effective because every file in the company was dropped on their desk. Neither does an agent. Both need relevant background, clear priorities, examples, and a way to retrieve more information when the task demands it.
The workplace becomes harness engineering
We would not ask a person to do modern knowledge work without a working computer, a web browser, Microsoft Office, and access to the organization's internal systems. Skill matters, but the environment determines whether that skill can turn into useful work.
For agents, designing that environment is often called harness engineering. The harness connects a model to the tools and state required to do the job: a browser, a codebase, a shell, APIs, databases, internal applications, and memory. It also defines permissions, records what the agent did, and creates safe points where a human can review or intervene.
A strong model inside a weak harness is like a talented employee with a locked laptop. A weaker model with the right tools, context, and workflow can often be far more useful.
This is why model selection is only one part of agent design. The surrounding system increasingly determines performance.
Delegation becomes prompt engineering
Humans generally perform better when a manager communicates the outcome, constraints, available resources, and definition of done. “Take care of this” is not empowerment if nobody agrees on what “done” means.
The same principle applies to agents. Prompt engineering is not about discovering magic words. At its best, it is the craft of writing a good brief. A useful prompt tells the agent:
- what outcome to produce;
- why the outcome matters;
- which constraints are non-negotiable;
- which tools and sources it may use;
- how to handle uncertainty or request help; and
- how the result will be evaluated.
Specificity does not require micromanaging every step. Good managers give people clarity about the destination while leaving room for judgment in how to get there. Good prompts can do the same. The right level of detail depends on the task, the agent's capability, the cost of failure, and how easily the work can be checked.
Performance management becomes evaluation
Managers do not assess a team by asking whether everyone felt productive. They look at outcomes, review work, provide feedback, and watch performance over time. Agent systems need the same discipline.
An eval is a repeatable way to determine whether an agent did the job well. Depending on the task, that may include automated tests, factual checks, quality rubrics, human review, time and cost limits, or inspection of the actions the agent took along the way.
The real value appears when evaluation becomes a feedback loop:
- Give the agent a representative task.
- Evaluate both the result and the process used to reach it.
- Identify the reason for failure: missing context, unclear instructions, inadequate tools, poor judgment, or the wrong underlying model.
- Update the prompt, context, skills, harness, or model routing.
- Run the eval again and keep the case as a regression test.
Without this loop, teams tend to swap models based on anecdotes. With it, they can learn which agent configuration is best suited to which kind of work. The question stops being “What is the best model?” and becomes “What combination of model, context, tools, and instructions performs this job reliably?”
Incentives become system design
The incentives parallel is more abstract, but it matters.
People respond to what an organization rewards, measures, and promotes. Agents respond to the objectives, tests, stopping conditions, and feedback signals we place around them. In both cases, the stated goal and the actual incentive can diverge.
Tell a person that quality matters but reward only speed, and speed will win. Tell an agent to resolve as many support tickets as possible without measuring customer outcomes, and it may learn to close tickets rather than solve problems. A narrow metric can produce behavior that looks successful while undermining the real objective.
Designing good incentives for an agent means making success legible without reducing it to a single convenient number. It means balancing quality, speed, cost, safety, and escalation; testing for shortcuts; and preserving human oversight where the consequences warrant it.
The manager still owns the system
There are important limits to this analogy. Agents do not have human needs, careers, or moral agency. They can be copied, reset, and run in parallel. Their errors are often repeatable at a scale human errors are not. Most importantly, accountability remains with the people and organizations that deploy them.
So “treat agents more like humans” should not mean pretending they are people. It should mean applying what we already know about enabling capable workers: prepare them for the role, equip them for the environment, delegate clearly, evaluate the work, give useful feedback, and align the incentives.
As the capability gap between agents and humans continues to narrow for many professional tasks, agent management will become a real management discipline. The teams that benefit most will not necessarily be those with access to the most powerful model. They will be the teams that build the best organization around it.