This is part three of Agentic Operating System For Your Business. Part one began with the Chief Agentic Officer Briefing. Part two followed the podcast until it met a very human publishing gate. This chapter is about choosing how the agentic workers themselves should be employed.

I have reached a choice that will be familiar to anybody who has built a company.

Do I build a permanent team, or do I use contractors?

In an agentic company, I think the equivalent choice is beginning to look like this:

The harness is the employee. The API is the contractor.

It is not a perfect analogy.

Contractors can remain with a company for years. Employees can leave tomorrow. An API route still needs engineering, and a harness is not literally a person.

But the analogy has helped me understand the decision I am making while building the Chief Agentic Officer Briefing.

Why companies use contractors

Contractors reduce a particular kind of risk.

You can bring in specialist capability quickly, scale it up when demand rises, and put it down when the job is finished.

You normally expect to pay more per hour because you are buying flexibility. You have not committed to building the whole employment environment around that person.

An API gives me something similar.

I can call an OpenAI or Anthropic model directly. I can route a different task through Kimi, DeepSeek, Mistral, or another approved model. I can test a local or sovereign deployment where jurisdiction, resilience, or privacy matters.

I can change the route without rebuilding the whole company around a single interface.

That flexibility is genuinely valuable.

It can also cost more for some long-running work, and it leaves me responsible for more of the operating environment.

Why companies build permanent teams

A good permanent team takes investment.

People learn the company, the customers, the language, the standards, and one another. They build working habits. They remember why a decision was made. They know where the files are, which tools are approved, what good looks like, and when to ask for help.

A mature harness such as Codex, Claude Cowork, Claude Code, or Kimi Code is starting to create a similar environment around the model.

You invest in its instructions, skills, permissions, connectors, memory, scheduled work, approval points, and access to the right context.

Over time, it becomes much better at doing coherent work inside your environment.

For the work I am doing, the harness often produces a better result with less operating friction. In some cases, its product economics are also much better than rebuilding the same long loop through direct API calls.

That feels like the advantage of a strong permanent team member.

They understand how the company works.

But what happens if the employee leaves?

The investment creates dependence.

What happens if the harness changes? What if a feature disappears? What if access is restricted in my country? What if the provider changes its price or scheduled-task limits? What if the whole route is unavailable when I need it?

That is the employee question in another form.

What happens if a valuable team member leaves?

I do not want to avoid hiring the best person merely because they might leave. That would be a strange way to build a company.

I also do not want the business to forget how to operate if one person is unavailable.

The model is only part of the worker

This experiment has made one thing very clear to me: the model is only part of the story.

The harness may manage files, tools, terminals, permissions, skills, memory, subagents, approvals, retries, checkpoints, and the conversation with the human.

That is not a decorative wrapper around an LLM call.

It is the environment that turns a model into a useful worker.

When I make a direct API call, I have not simply moved the same employee onto my server. I have hired the underlying specialist and taken responsibility for the office, systems, processes, supervision, and handoffs around them.

I explore that architecture in more detail in Use The Harness. Keep The Escape Route. This chapter is about what the choice means while I build the company.

My current answer is not either-or

I am still experimenting.

For frontier work where capability changes the outcome, I am likely to use the strongest harness available. That is where the permanent-team investment can pay off.

For narrower, repeatable, high-volume, jurisdiction-bound, or cost-sensitive work, an API, smaller model, or approved local model may be the better contractor.

So I need two test benches.

  • The employee bench: How good is the outcome when the worker has the full harness, tools, skills, and accumulated context?
  • The contractor bench: Can the same business job run through an API, another provider, or a local route with acceptable quality, cost, evidence, and human effort?

I need to measure both.

Not model benchmarks. Actual business outcomes.

  • Did the work finish?
  • Was it correct?
  • What evidence came back?
  • How much human correction did it need?
  • How long did it take?
  • What did it cost?
  • Could another person understand the receipt?
A comparison of a permanent-team harness and a contractor-style API route, both working from the same Orchistra job contract and measured by outcome, quality, cost, evidence, human effort, and resilience.
The employee and contractor routes should be measured against the same business job.

The company must remember outside the worker

Whichever route I use, the business meaning of the work cannot live only inside that worker.

The goal, authoritative context, constraints, required capabilities, evidence standard, approvals, budget, success condition, and final receipt need to remain portable.

For me, that is part of the role of Orchistra.

Orchistra should understand the work, the route, the owner, the budget, the evidence, and the result. The employee or contractor performs the work. Neither should become the only place that knows what the job was.

Where I am now

I know that working with a good permanent team is generally better for a company.

There is shared context, coherence, trust, and accumulated understanding.

I also know that flexibility matters, and that operational resilience requires another route.

So I am building and measuring both.

I will invest in the harness where it gives the Chief Agentic Officer business the strongest worker.

I will keep the API and local routes available where they give me flexibility, cost control, sovereignty, or resilience.

And I will make sure the company remembers how the work is done outside either of them.

We will see whether the employee-and-contractor analogy travels.

I suspect it will.

In this series

Sources and notes

The employee-and-contractor comparison is my working analogy, not an industry classification. Product capabilities, access, and pricing change. The sources below describe the current harness and deployment options that informed the field note.