Hiring an AI Orchestrator to Fix a Spreadsheet Problem
Most businesses asking for agents need a process first. Some of them just need a spreadsheet.
___________________________________________________________________________________________________________________________________________________________________________________________
AI Agent Orchestration Specialist. Agentic Workflow Engineer. n8n Expert Needed Urgently. I can't remember the last time I saw a posting for a prompt engineer. It's all agent orchestrators now, and next year it will be something else. The titles change. The pattern underneath them doesn't.
Read past the title and into the requirements, and a surprising number of these jobs describe something else entirely. Reconcile invoices. Chase overdue approvals. Pull three reports nobody reads into one report somebody might. Keep track of stock. Post to social media on a schedule.
None of that is an intelligence problem. Most of it is a management problem, and some of it is a spreadsheet problem. AI can help with both. But the job being advertised is rarely the job that needs doing.
___________________________________________________________________________________________________________________________________________________________________________________________
The Tender
The tender that finally pushed me to write this crossed my desk recently, and I want to be fair to it, because it is one of the better-written briefs I've seen.
A small group of businesses, all run by one person, wanted a contractor to build an "AI-powered operating engine": multiple agents on a shared data layer, covering finance, operations, content, research, sales sourcing, sales outreach, a KPI dashboard, and a "challenger" agent to stress-test the owner's strategy. A fixed price in the low thousands of dollars. Ninety days. A small paid trial to choose between shortlisted candidates. A cloud accounting platform across several entities, plus e-commerce and marketplace integrations, plus a private/team permission split, plus full documentation for handover to an in-house developer.
The good parts are genuinely good. It insists on a shared data layer so the agents form a system rather than multiple disconnected bots. It has an absolute rule that no agent sends, posts, contacts a customer or files anything with the tax authority without human approval. It builds access control in deliberately, keeping detailed financials private and headline numbers shared. It names the accounting platform as the system of record and says the agents don't replace it. It has a properly explicit out-of-scope section. Whoever wrote it understands governance better than most enterprise buyers I've worked with.
And then there's the paragraph bidders are told to read before pricing. It explains that these are early-stage, pre-launch businesses. One has a handful of transactions. Another is near-dormant. Some of the accounting ledgers will be opened blank. By the brief's own account, there is very little existing data.
Read that again, alongside the request for multiple agents.
___________________________________________________________________________________________________________________________________________________________________________________________
What the Agents Would Actually Do
Take the finance agent first. Its job is to ingest bank statements, categorise transactions into the accounting platform, prepare reconciliations and produce a monthly pack. For a business with a handful of transactions a month, that is an afternoon's work. It is also, increasingly, the accounting platform's own job. The major cloud packages have categorised recurring transactions with bank rules for years, and at least one now uses AI to auto-reconcile bank lines when it is highly confident of a match, while letting you reject anything it gets wrong [1]. The agent would be wrapping an LLM around a feature the platform already ships.
The operations agent keeps production batch records, regulatory records, stock-on-hand and work-in-progress, and calculates unit cost and wastage. Every one of those is a table. Unit cost is a formula. Regulatory records may need audit trails and retention rules that an ordinary spreadsheet handles poorly, but that's a reason to choose the right record-keeping tool, not a reason to build an agent. The e-commerce platform already tracks inventory. The hard part of operations at this stage isn't data processing. It's deciding what the records should be, who fills them in, and when.
The KPI dashboard pulls sales, marketing and production numbers into one shared view. At pre-launch volumes, that's a sheet with a chart on it, refreshed from the other sheets.
Which leaves the shared data layer, the architectural centrepiece of the whole brief: one place where every function writes its outputs, so that cross-cutting analysis like margin becomes a simple query. That is exactly the right idea. It also already has a name. It's called a well-structured spreadsheet. At this scale, a workbook with one tab per function, a consistent product and customer key across all of them, and a margin tab that looks up price, volume and unit cost does everything the brief's own worked example asks for. It costs nothing, the owner can read every cell of it, and it will happily carry the businesses until volume makes something heavier worth building.
That is an over-simplification, and I know it. But it is a useful one, because it tells you where the real work is. The spreadsheet only works if somebody decides what goes in each tab, who updates it, and what "correct" looks like. That decision is process design. An agent can't make it for you. It can only automate whatever you decided, or, if you didn't decide, improvise.
___________________________________________________________________________________________________________________________________________________________________________________________
The Bottleneck Is the Owner
Here is the part of the brief that worries me most, and it comes from its best feature.
Every agent includes a human-approval step. The human is the owner, in almost every case. So one person running several pre-launch businesses would be reviewing drafted posts for every brand plus a personal one, outreach messages before each one sends, supplier and regulatory decisions, finance outputs before anything is filed, research briefs, and a stream of provocations from the challenger agent.
The scarcest resource in a one-person group of companies isn't data processing. It's the owner's attention. Multiple agents with mandatory approval don't reduce the demand on that attention. They multiply it, and they do it in a queue the owner didn't have before. The approval rule is right. Applied to multiple agents, it turns the owner into a full-time reviewer of machine-drafted work. Human-in-the-loop isn't a governance design unless you've modelled the capacity of the human in the loop.
A process redesign would start somewhere else entirely: which of these activities matter right now, pre-launch, and which can wait until there are customers? That question has no AI in it.
___________________________________________________________________________________________________________________________________________________________________________________________
The Price Tells You the Rest
Multiple agents, a shared data layer, a multi-entity accounting integration, e-commerce and marketplace connections, a permission model and full handover documentation, over ninety days, for a fixed price in the low thousands. That's a few hundred dollars an agent, infrastructure included.
I'm not criticising the budget. It's a small business, and it priced to its means. The number is interesting because of what it reveals about the belief behind it: that agents are cheap to build. The build may well be. An agent that drafts something is easy. The cost is in everything after the demo: LLM credits on every run, integrations that break when a platform changes its API, prompts that drift as models are updated, and a developer on retainer to keep multiple probabilistic workflows behaving the same way next month as they did this month. The brief even says, sensibly, that the system must be built "for growth." But building for scale before there is anything to scale means paying the running costs of a system sized for a business that doesn't exist yet.
___________________________________________________________________________________________________________________________________________________________________________________________
It Isn't Only Small Businesses
None of this is unique to a one-person startup group. It's just easier to see at that size.
In June 2025, Gartner predicted that over 40% of agentic AI projects will be cancelled by the end of 2027, citing escalating costs, unclear business value and inadequate risk controls. Its analyst Anushree Verma described most current projects as "early stage experiments or proof of concepts that are mostly driven by hype and are often misapplied," and added the line every buyer should pin above their desk: "Many use cases positioned as agentic today don't require agentic implementations" [2]. Gartner also estimated that only about 130 of the thousands of vendors selling "agentic" products offer anything genuinely agentic. The rest are chatbots and robotic process automation in new packaging, a practice it calls agent washing [2]. A year on, the same pattern is still being reported: governance, unclear value and the gap between demos and production [3].
MIT's NANDA initiative reported in July 2025 that, despite $30–40 billion of enterprise investment in generative AI, 95% of the organisations it studied were getting zero return [4]. The study's methodology has been argued over, and I'd treat the exact figure with caution. But its diagnosis is the interesting part. The problem wasn't model quality. It was a learning gap: "most GenAI systems do not retain feedback, adapt to context, or improve over time" [4]. And while more than half of generative AI budgets went to sales and marketing tools, Fortune's reporting on the study found "the biggest ROI in back-office automation": cutting outsourcing and agency costs and streamlining operations, the least glamorous part of the business [5].
Put plainly: AI tends to fail where the workflow is undefined, and pays where the workflow is well understood.
___________________________________________________________________________________________________________________________________________________________________________________________
Two Clients, Two Lessons
The tender is one example. Two engagements of my own from earlier this year make the same point from opposite directions.
The logic layer. The first was a founder building a SaaS platform for cataloguing equipment. His posting asked for an AI enrichment service: recognise the equipment from a photo, find its manual, extract the specifications, suggest a price. It was an unusually literate brief. It asked for gated writes, so AI outputs arrived as proposals rather than overwriting real data. It asked for observability, replayable jobs and confidence scores with evidence. Somebody had clearly thought about governing AI.
Over the following weeks, a different problem surfaced. The AI functions weren't what was stuck. What was stuck was the logic around them: what state an equipment entry was in, what was allowed to happen next, and how much evidence the system needed before it trusted a result. He tried decision trees. He tried swimlane diagrams. He tried a spreadsheet, which he said felt like it was missing a dimension. Eventually his team started building an orchestration layer in n8n to run experiments on combinations of rules and ranking approaches, hoping the right structure would fall out of the testing.
He put it better than I could. The value, he said, was in the logic layer; the AI backend functions, anybody could code. He was right. What he needed wasn't more orchestration. It was a small governing model: a handful of states that matter, the transitions between them, and the evidence required before each transition is allowed. That is process design for a system with an AI in the middle of it, and it was the one deliverable he wanted to get through conversation rather than commission. When the questions grew detailed enough to be the design itself, I said so, and suggested proper design sessions instead of fragments of conversation. I never heard from him again, and the posting was later closed.
That's the second lesson inside the first. Buyers who think the AI is the expensive part expect the thinking around it to be free. It's the other way round.
The job with almost no AI in it. The second engagement, which I'm still involved with, came from a posting for senior engineering help on an established platform business. Like most postings this year, it put real emphasis on AI: AI-assisted development, AI code review, AI-assisted debugging and refactoring.
The work that actually needed doing was infrastructure, data and architecture work on a system that had evolved over many years: the unglamorous kind that keeps a business running. Almost none of it needed AI inside the product. Two further projects have grown out of it since, and the same is true of them.
But AI has been everywhere in how the work gets done. Reading unfamiliar legacy code. Drafting reviews. Analysing slow queries. Stress-testing a migration plan before anyone touches production. That is AI exactly where it belongs: in the hands of the people doing the work, accountable for every line, and nowhere near the system's critical path unless it has earned its place there.
There's a postscript I enjoy. The person who found me for that role told me afterwards that he'd started with deep research on an AI tool, which put me near the top of its list of candidates. He used AI to help him decide. Then a human interviewed me, a human checked my code, and humans made the call. Guidance, not the whole solution.
___________________________________________________________________________________________________________________________________________________________________________________________
Automating the Mess
There's an old rule usually credited to Bill Gates: automation applied to an efficient operation magnifies the efficiency, and automation applied to an inefficient operation magnifies the inefficiency [6]. Whoever said it first, it has never been more true than it is for agents.
Traditional automation at least fails consistently. A broken macro breaks the same way every time, and somebody eventually notices. An agent pointed at an undefined process does something worse. It fills the gaps with plausible guesses, and guesses differently each run. The mess that used to be slow and visible becomes fast and hidden.
I've argued in earlier pieces that the useful questions about any AI system are capability, reach, autonomy and authority: what can it do, what can it touch, how long does it act before a human checks in, and who granted it permission and owns the result. There's a question that comes before all four, and most of these job postings skip it.
Is there a defined job for the system to do at all?
___________________________________________________________________________________________________________________________________________________________________________________________
The One-Page Test
Before you hire an agent orchestrator, or buy an agent platform, or post a tender for multiple agents, try this.
Write the process on one page. Not the vision, the process: the inputs, the steps, and the output.
Then answer five questions about it. Who owns each step? What does "done" look like, and how would you know if it was wrong? How often does it happen: daily, weekly, twice a year? What does a mistake cost? Could a competent temp follow this page on their first day?
If you can't write the page, you don't have an AI problem. You have a process design problem, and an agent will automate your confusion at scale.
If you can write the page, look at it honestly. A surprising amount of the time, what you've described is a form, a spreadsheet, a scheduled report, or a set of plain if-this-then-that rules. n8n, the tool half these postings ask for, is an excellent workflow engine that doesn't need an LLM at all for deterministic automation. Rules are cheap, predictable and auditable. Use them for everything they can do, and save the model for the steps that genuinely need judgement or language.
Automation and agency aren't the same thing. A workflow can be sophisticated, cross-system and almost entirely automated without an agent ever deciding what happens next. Automate everything deterministic first, and use an agent only for the steps that genuinely require judgement under uncertainty.
And sometimes, once the page exists and the process has run reliably for a while, an agent will earn its place. That's the right order.
___________________________________________________________________________________________________________________________________________________________________________________________
Where AI Actually Belongs
None of this means "don't use AI." It means use it where it's strong, which is in helping you think, not in standing in for thinking you haven't done.
A good model can be a superb process-design partner. Describe how work actually flows through your business and ask it to map the steps, find the duplication, and draft the one-page process. Paste in your last three months of transactions and ask it to propose a categorisation scheme. Ask it to help identify what a pre-launch manufacturer may need to track for regulatory purposes, then verify what it tells you. Ask it to find the holes in your plan.
That last one is the challenger agent from the tender, and it's the best idea in the brief. A sharp, contrarian thinking partner that reads your plans and asks the questions a good co-founder would. It's also available today, for the price of a monthly subscription, in a chat window, with no shared data layer, no n8n server and no multi-thousand-dollar build. The owner could start using it this afternoon.
The research agent is in the same category. So is much of the content drafting. These are conversations with a capable model, run by a human who decides what to keep. They don't need orchestration. They need a person who knows what they're asking for.
___________________________________________________________________________________________________________________________________________________________________________________________
What I'd Propose Instead
For a brief like this, I'd propose something smaller and, I think, more useful.
Two weeks of process design first: sit with the owner, write the one-page process for each business function that actually matters pre-launch, and decide what can wait until there are customers. Then switch on what the existing tools already do: the accounting platform's bank rules and auto-reconciliation, the e-commerce platform's inventory, a scheduler for content. Build the shared data layer as a structured workbook with a margin tab, exactly as the brief's own worked example describes. Give the owner a good model for research, drafting and strategic challenge, with a short guide on how to use it well. And agree a trigger, a transaction volume or a headcount, at which the first real agent gets built, on top of a process that by then has been proven by running it.
It would cost less, it would ship in weeks, and at the end of it the owner would understand their own businesses better than any set of agents could have taught them.
___________________________________________________________________________________________________________________________________________________________________________________________
The Skill Nobody Advertises For
Which brings me back to the job titles.
The skill most of these companies are missing isn't agent orchestration. It's the oldest, least fashionable skill in operations: looking hard at how work actually gets done, deciding how it should get done, and writing it down so that anyone, human or machine, can follow it. You can call it process design, or business analysis, or just good management. It doesn't trend on LinkedIn. Nobody is posting tenders for it.
But it's the job that has to be done before any agent can do its own, and in a remarkable number of cases, once it's done, the agent turns out to be optional.
___________________________________________________________________________________________________________________________________________________________________________________________
Sources
[1] Xero, "Automatic bank reconciliation software by JAX." https://www.xero.com/us/accounting-software/reconcile-bank-transactions/
[2] Gartner, "Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027," press release, June 25, 2025. https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027
[3] Robert Szczerba, "Why 40% Of Agentic AI Projects May Be Canceled By 2027," Forbes, July 7, 2026. https://www.forbes.com/sites/robertszczerba/2026/07/07/why-40-of-agentic-ai-projects-may-be-canceled-by-2027/
[4] Aditya Challapally, Chris Pease, Ramesh Raskar and Pradyumna Chari, "The GenAI Divide: State of AI in Business 2025," MIT NANDA, July 2025. https://mlq.ai/media/quarterly_decks/v0.1_State_of_AI_in_Business_2025_Report.pdf
[5] "MIT report: 95% of generative AI pilots at companies are failing," Fortune, August 18, 2025. https://fortune.com/2025/08/18/mit-report-95-percent-generative-ai-pilots-at-companies-failing-cfo
[6] APQC, "Why Process Automation Won't Cure Inefficiency" (quoting the rule attributed to Bill Gates). https://www.apqc.org/blog/why-process-automation-wont-cure-inefficiency