In 2026, working with an AI agent has become a daily reality for many tech teams.
An agent is a program capable of executing a sequence of tasks autonomously: answering customer requests, qualifying leads, guiding a user through onboarding (without human intervention at every step).
What felt experimental two years ago is now running in production across hundreds of European companies.
The catch is that an agent does exactly what it's been told to do. Nothing more. Which means that before any technical decision: which model, which architecture, which integration, a team needs to describe its work with a level of precision it has never needed before. Not a rough outline. A description precise enough that both a human and a machine could follow it and produce the same result.
In May 2026, Anthropic and OpenAI each announced the launch of an enterprise services division, backed by Blackstone, Goldman Sachs and TPG. Behind both announcements, the same diagnosis: the models are ready, the organizations are not. The bottleneck isn't technical capability. It's the ability to describe, clearly and completely, what needs to happen.
The work no one has done yet
Most Series A founders who launched an AI project in 2024 or 2025 started with a reasonable brief: "we want a RAG on our support documentation", "we want an agent to handle first-line customer queries", "we want a copilot for the sales team." The technology was scoped, built and shipped. And in most cases, very little changed in the business.
The reason is almost always the same. When you ask an engineering team to build an AI agent for customer support, they will build exactly that. What they won't do (unless someone explicitly asks) is map out every case the agent will encounter, define what a good response looks like in each situation, identify where escalation to a human is necessary, and specify what happens when the agent doesn't know the answer.
That work isn't technical. It's operational. And in most companies, it has never been written down because it has never needed to be.
Experienced support reps handle edge cases instinctively. They know when to escalate, when to bend the rules, when a customer needs a human. That knowledge lives in their heads.
An agent has no head. It has a process and if that process hasn't been documented, the agent will either fail silently or produce outputs that look correct but aren't.
Why formalizing process feels uncomfortable
There's a reason this work gets skipped. Mapping a process in enough detail to hand it to an agent exposes things organizations would rather not examine. Gaps in coverage. Inconsistencies between how different people handle the same situation. Decisions that were never made explicitly and have been improvised ever since.
According to McKinsey, companies that invest in process documentation before deploying AI are 2.5 times more likely to report measurable business impact within twelve months. The investment isn't in the model. It's in the clarity that makes the model useful.
This is precisely what Dario Amodei pointed to when announcing Anthropic's new services venture: enterprise demand for Claude is significantly outpacing any single delivery model. The constraint isn't what the model can do. It's whether the organization can describe what it wants done precisely enough for the model to do it reliably.
What process formalization actually looks like
At Nightborn, every AI project starts with the same question: can you describe this process step by step, in enough detail that someone who has never done it before could follow it and produce the right result? Not the happy path. Every path including the exceptions, the edge cases, the moments where judgment is required.
This typically takes the form of a structured documentation sprint before any technical work begins. The goal is to produce something specific: a process description precise enough to be handed to an agent, with explicit decision points, defined outputs, and clear escalation rules. "Reduce ticket resolution time from 8 minutes to 3 minutes" is a useful KPI. But it only becomes actionable once someone has mapped exactly what happens between a ticket being opened and being resolved (every step, every variation, every exception).
The model comes after. The architecture comes after. What comes first is a description of the work that is precise enough to be executable by a human or a machine.
That's the discovery work Nightborn runs before writing a single line of code.
For teams that want to know where to start, the first question is always the same: can you write down, in full, exactly how this process works today? If the answer is no, that's where the work begins and that's where we come in.
.webp)