The second chapter of The Orchestrator is now live: “You May Already Be an Orchestrator.”

The title is not a prediction about some distant job category. It describes work that is already happening.

You may already be doing this work.

The chapter opens with Maya, a senior engineer whose official title is still “platform engineer,” while three agent workflows are already helping her connect customer complaints, product decisions, repositories, tests, and release signals. She is not merely asking a model to write code faster. She is directing several systems that read different kinds of evidence, compare possible actions, and decide what deserves attention next.

Her organization has not named that responsibility yet. It has not staffed it, budgeted for it, or put it on the org chart. Maya is doing it anyway, mostly because she got tired of waiting three weeks of meetings for an answer she could reach in a few minutes.

That is the part of the chapter I wanted to sit with. The important change is not that people have access to another tool. The important change is that some people are beginning to automate the work around the code: the customer analysis, the prioritization, the test design, the impact estimate, the release plan, and the handoffs that used to consume the week before anybody touched the actual problem.

That’s describing the change to Maya’s job in an incremental way. She’s getting more productive doesn’t really capture it because when you start to compare Maya to her peers who have not yet learned how to orchestrate AI, you start to see an entirely different job function. That’s what many of us are already experiencing.

Maya’s focus on Orchestration over Development has changed the shape of the work. The old process still exists around her: support summarizes tickets, product requests a spreadsheet, engineering creates a Jira issue, teams schedule planning meetings, QA waits for a build, security reviews the change, and release engineering decides whether the fix can go out. Every group is performing a reasonable function. The whole system is still slow because it is organized around the movement of information between teams rather than the outcome somebody is trying to achieve.

The meetings are not necessarily foolish. That is what makes this harder. A specialist team needs context. A security review can catch a real problem. A release process can keep a bad change from reaching production. The machinery exists for reasons, and some of those reasons are good.

But when a person with a set of agents can read the original customer evidence, generate useful tests, inspect the relevant repository, model several options, and produce a compliance-scanned fix before the first planning meeting happens, the question is no longer whether the machinery is reasonable in isolation. And the question isn’t how much does the AI cost to automate, I think the real question is how much opportunity does it cost the organization to ignore the difference in speed. Using the right tools, Maya can achieve more in a few hours than a meeting-driven organization can achieve over several weeks.

The chapter uses Maya’s workflow to make that cost visible. A customer reports a broken returns process. The report is tagged, summarized, exported, turned into a presentation, requested again as a spreadsheet, discussed in a meeting, converted into a ticket, placed in a backlog, estimated in sprint planning, delayed by another review, and eventually assigned to Maya after the original engineer has had enough. Maya’s orchestrated systems already had a series of revenue and compliance-tested fixes waiting for her to merge before anyone even got to the office.

The organization did not fail because any one person was incompetent. It failed because every handoff preserved the structure that produced the handoff. The system wasn’t designed to move quickly. It was designed to identify what was the next team that “owned” the outcome. A lot of our existing corporate systems focus less on customer outcomes and more on the political power structures within an organization. It’s the immediacy of inference engines that poses a challenge to continuing to be delayed by this.

That is why people who learn to orchestrate these systems can be careful about revealing what they are doing. It is not hard to understand the fear. If your work has been defined by reading the queue, preparing the summary, attending the meeting, and passing the result to the next specialist, a system that connects those steps does not look like a neutral efficiency improvement. It looks like a question about why the steps were separate in the first place.

And this is happening before most companies have decided what an orchestrator is. The title will eventually appear in job descriptions, compensation bands, and organizational charts. By then, the people doing the work will have already learned the difficult parts: how to divide responsibility between systems, how to check their output, how to decide when a model is wrong, and how to make a result useful to people who were not in the loop.

While this job title is still emerging, you probably already have the job.

Read Chapter 2, “You May Already Be an Orchestrator,” now. Then look at the work you are doing that your job title still describes as something smaller.

HQ 8 — Authored. This is my work. A tool helped me catch errors.