New competencies for working with agents

6.1. Understanding the technical unit you work with

It is useful to distinguish model, agent, and execution environment. The model produces responses and tool-use decisions. The agent is the system that organizes those interactions over the course of a task. The environment provides files, processes, network, credentials, and resources. The term harness refers to the infrastructure that coordinates the loop and its interfaces.

A deficiency can lie in any layer. An agent may have sufficient reasoning ability and fail because it cannot run the test, received outdated documentation, or lost the state of the work. This distinction makes it possible to fix the right cause instead of just changing the wording of the request.

Minimum expected fluency: understanding the context window, information retrieval, tool use, variability between runs, time and cost budgets, permissions, state persistence, and environment limits. Knowing how to use one tool end to end is more useful than superficially knowing many names.

6.2. Specifying delegable work

A delegable task needs to clarify the outcome and the conditions under which it will be considered correct. The greater the intended autonomy, the more important it is to make explicit the ambiguities that would change the solution.

A good task contract answers:

1. What outcome do we want, and for whom?
2. What behavior needs to exist?
3. Which invariants and constraints must be preserved?
4. Which sources of context are reliable?
5. What is the perimeter of the change?
6. What evidence will demonstrate completion?
7. What situation requires a human decision?

This can fit in a few lines for a simple fix. For a broad change, it may require interface design, examples, domain decisions, and a migration plan. The goal is to reduce relevant uncertainty, not to produce documents for the sake of volume.

Spec Kit, published by GitHub in 2025, is an example of a tool that organizes specification, planning, tasks, and implementation. The durable capability is formulating verifiable intent; adopting that particular kit is a process choice. F27

You also need to know what to leave open. Specifying the latency limit and the contract of an operation may be necessary; choosing every class in advance can reduce the agent's freedom without improving the result. Good contracts constrain important properties and leave room to explore the implementation.

6.3. Context engineering

Context engineering is organizing the information available to the agent during the work: requirements, rules, code, documentation, tools, execution results, and task state. Anthropic describes this activity as continuous curation, with on-demand retrieval and maintenance of relevant information. F17

The practical application proposed here has three layers:

The engineer should identify the source of authority for each piece of information. A current architectural decision, a hypothesis recorded during an investigation, and a suggestion found in an issue do not carry the same weight.

Each important document needs a purpose and some update mechanism. When there is a conflict, there should be a way to resolve it. Accumulating old and contradictory instructions increases the work of interpretation.

A high-value detail is making results retrievable: file paths, test identifiers, code version, and links to decisions. A summary that says “the tests passed” is less useful than a record that lets you locate which tests, against which version, and with what result.

6.4. Preparing the repository for independent execution

OpenAI's account of harness engineering describes a short orientation file that works as a map to more detailed documentation, along with isolated environments and access to execution signals. This case illustrates the importance of making the project understandable and operable by agents. F06

As a practical proposal, a prepared repository should let a new executor discover how to install dependencies, start the system, run the relevant checks, and understand architectural boundaries. It should also provide suitable test data and explain what to do when an external dependency is unavailable.

This does not require moving all of the company's knowledge into a single file. The work consists of building reliable paths to the necessary information and eliminating steps that depend on personal memory or repeated manual intervention.

Readiness test: can a team member unfamiliar with the module, or an agent in a fresh session, reproduce a failure and run the relevant validation using the available instructions? The difficulties they encounter are concrete opportunities for improvement.

6.5. Tools, APIs, CLIs, and MCP

The engineer should understand how to connect agents to the actions and information they need. This includes command-line tools, APIs, connectors, and protocols such as MCP, depending on the environment in use.

Interface design matters: clear names, typed arguments, understandable results, useful errors, and well-bounded operations make tools easier to use. Anthropic's article on tools recommends testing these contracts on realistic tasks and holding out cases for evaluating changes. F18

A deployment tool, for example, might require environment, version, and operation identifier, return a queryable state, and make it possible to distinguish “request accepted” from “deployment completed.” An interface that just runs a command and returns free text can make that distinction harder.

The criterion for adopting MCP or building your own tool is solving an integration need. An existing, well-documented CLI may be enough. The professional should know the options and weigh maintenance, authorization, observability, and ergonomics; there's no need to wrap every operation in a new framework.

6.6. Reusable procedures and skills

A skill can bundle instructions, scripts, examples, and resources for a type of work. The Agent Skills proposal published by Anthropic uses progressive loading of this information to specialize execution according to the task. F19

A good starting point is a recurring difficulty. If every migration requires the same delicate steps, they can become a verifiable procedure. If every performance investigation requires locating the same signals, a shared resource can reduce the setup.

A skill should have criteria for when to use it, inputs, expected outcome, and verification. It needs to be tested on representative cases and revised when the environment changes. A set of instructions that seems sensible but has never been exercised is still a process hypothesis.

It is useful to separate guidance from deterministic execution. When a transformation can already be performed by a reliable function or script, the agent can select and run that tool rather than regenerating its logic each time.

6.7. Decomposition, parallelism, and integration

The engineer needs to recognize dependencies before distributing tasks. Independent fronts can proceed in parallel; shared decisions that are still undefined need to be resolved or have a clear owner.

Good candidates for parallelism: investigating distinct subsystems, reviewing different risks, exploring architectural alternatives, and implementing modules against already-agreed interfaces.

Situations that call for coordination care: several agents changing the same infrastructure, incompatible versions of an API, dependent migrations, or a common cause that blocks every front.

In its April 2026 revision, Towards a Science of Scaling Agent Systems found performance to depend on the combination of architecture, task, and resources, including losses in poorly aligned configurations. The study offers an empirical reason to treat coordination as an engineering choice. F21

A useful practice is to define an owner for each change, integration contracts, and synchronization points. Separate worktrees or clones, each with its own branch, and isolated environments reduce file and execution collisions. Branches alone do not isolate two processes in the same working directory. Integration still needs to verify the semantics of the whole: two changes can compile separately and contradict the same business rule.

6.8. Managing continuity and the economics of execution

Prolonged autonomous work requires persistent state, stopping criteria, cost limits, and recovery mechanisms. The engineer needs to know when to resume a run, when to restart with better context, and when to ask for a missing decision.

In March 2026, Anthropic described an architecture with separate planning, generation, and evaluation for long-running application development. The account also shows that model improvements can make components of an earlier harness unnecessary. The implication is to revisit the process as the tools evolve. F07

As a design rule, record the goal, proven progress, decisions, blockers, and next action. Stop loops with no observable progress. An agent that repeats the same attempt needs a diagnosis, new information, or a different task.

The relevant cost includes inference, tools, CI, waiting, and human attention. The cheapest model per call can turn out expensive if it requires many corrections. The choice should consider cost per accepted result and quality across the real set of tasks.