Stop Asking Where to Put AI Agents. Map the Real Process First
What two years of process discovery at a telecom company taught me about designing agentic workflows that survive contact with reality
Building an AI agent prototype can take an afternoon. Getting an agentic workflow to run reliably inside an existing organization is a much bigger engineering challenge.
The work of Forward Deployed Engineers (FDEs) illustrates why. These engineers work directly with customer teams on discovery, technical scoping, system design, and production rollout. Understanding how work actually gets done is part of building a system that fits the organization.
Many organizations start their AI adoption with the wrong question. They look at an existing department and ask: “Which steps of our process can we hand over to an agent?”
Years ago, before I moved into software engineering leadership, I spent two years as an IT Process Manager in the shared service center of a multinational telecom company. My job was to work with teams across four countries, understand how work moved across hundreds of people, and redesign core workflows from incident response to software delivery.
Watching teams design agentic workflows today, I recognize the exact same structural traps I saw back then. Before you can decide where an AI agent belongs in an organization, you have to confront an uncomfortable reality: your documented process is rarely how the work actually gets done.
The Document Is Not the Process
When teams set out to build an agentic workflow, their first instinct is often to gather the “source of truth.” They pull the onboarding slides, the Confluence pages, and the standard operating procedures (SOPs), feed them into a context window or a retrieval pipeline, and expect the agent to follow the rules.
When I started my first assignment at the telecom shared service center — redesigning Incident Management across several markets — I went looking for the official process document too. I found three: one from 2010, one from 2014, and a third living on an internal wiki. Large parts of the 2014 version had been copied from a generic template.
None of them matched what people were doing day to day.
So I closed the documents and ran whiteboard sessions with the teams. I sat with the Service Desk, billing operations, database administrators, and support specialists across countries, and asked them to draw how a ticket actually moved through their shift. Not how it should move. How it did.
When I returned to my desk, I wrote every specific complaint and bottleneck from those sessions onto its own sticky note — around 40 in total — and grouped them into eight themes.
I expected the largest theme to say We have no process. It didn’t.
The largest cluster on my desk was Procedures exist, and nobody follows them.
- Unowned handoffs. A specialist group would fix a technical issue but leave the ticket open because closing rules were unclear, sending the ticket back and forth across teams.
- Ambiguous statuses. When engineers got blocked, they placed tickets into
Pending. Across the groups I interviewed,Pendingwas used to mean four different things: waiting on a customer, waiting on an external vendor, waiting on a maintenance window, or "I am working on something else right now." - Whiteboard question marks. The database team drew their flow and wrote in the margin:
(!) Not clear dispatching process.The Service Desk listed the four official incident categories and wrote???after the last one. - Missing tool access. One sticky note sat in its own category: “Some teams don’t have access to the ticketing tool at all.”
In the manufacturing flowcharts I used earlier in my career, we drew solid lines for the planned production flow and dashed lines for the rework and reject paths nobody liked to talk about. In service and software organizations, those informal workarounds often carry the entire operation.
Every question mark on a team’s whiteboard is a signal to investigate — identifying a point where rules or responsibilities need checking before you try to automate.
If you build an agent purely on top of your official SOPs, you are designing for an imaginary organization.
Speeding Up a Box Doesn’t Always Speed Up the System
Once I had the complaints from the interviews, I printed out the baseline incident flow and marked every spot where the friction landed. The main pain point wasn’t ticket logging or initial diagnosis — which is where most process documents (and many AI pilots) focus their attention. It was functional escalation: the handoff where a ticket moved from first-line support to a specialist team in another country. That was where tickets bounced, waited, and lost context.
Later, when I analyzed our central software delivery factory, I saw the same dynamic at a larger scale. Taking a cross-system change from initial request to production took 12 to 18 weeks. One historical integration change I reviewed had gone through an initial triage, an impact analysis, a walkthrough, a solution description, and six versions of a design deck over nine months before detailed design was finished.
The cycle wasn’t slow because engineers wrote code slowly. It was slow because the organization ran on five different delivery rhythms at once, and work spent weeks sitting in queues between handoffs.
Speeding up work inside an individual step matters when that step is the true constraint. But as Michael Hammer argued in his classic 1990 Harvard Business Review essay, “Reengineering Work: Don’t Automate, Obliterate,” organizations routinely automate existing tasks inside departmental silos while leaving the fragmented handoffs between them untouched.
This is one reason task-level gains from coding or operations copilots may not translate into shorter end-to-end lead times. Optimizing inside Box 4 has limited impact if the main delay remains in the exception loop between Box 4 and Box 5.
Semantic Seams: Four Teams, Four Definitions of “Global”
Even when each team has a sensible local workflow, automation breaks at the boundaries between them.
In my second year at the telecom company, a change built for one market disrupted a service in another. The post-mortem pointed to an obvious gap: the cross-country impact should have been caught during analysis.
Get Jekaterina Jegoscenko’s stories in your inbox
Join Medium for free to get updates from this writer.
Instead of simply adding a rule telling teams to “check for global impact,” I sent the same short questionnaire to the leads of four core system teams — CRM, billing, middleware integration, and service delivery:
- What is a “global change” in your system?
- When do you find out a change affects other countries?
- Who approves it, and how is it tracked in Jira?
I received four different answers. One team identified global impact after system design. Another caught it during high-level analysis — if the business requirements were clear — and otherwise during development. In three of the four systems, formal global approval did not exist at all; it depended on a Solution Architect recognizing the dependency and raising it in a meeting.
Each team was following its own local logic. The risk lived in the gap between their definitions.
Look at how organizations wire multi-agent workflows across departments today. An intake agent passes structured state to a triage agent or a fulfillment workflow, assuming terms like Global, Ready, Customer, Escalation, or Done carry the same meaning everywhere. They rarely do. Every team develops its own local dialect.
Before connecting automated workflows across team boundaries, someone has to align the definitions. In our case, that meant establishing a five-level escalation ladder (Level A at initial intake down to Level E inside an active sprint) so every system team shared the same criteria and approval path whenever a change crossed borders.
Where Do Agents Actually Belong?
Midway through my time there, I was asked to design a common end-to-end delivery process for 15 cross-functional teams across seven countries. Working through that design with the teams taught me a sorting discipline that applies directly to building effective agentic systems.
“Map the process first” does not mean freezing the organization for six months to write a master specification. It means picking one bounded workflow, tracing real cases end to end, and passing every step through a ruthless triage before you decide what to build.
First, question steps that have no clear owner or purpose (The TBD Box Test). In one of my early diagrams, a box labeled TBD sat right in the middle of the flow, connected to multiple paths. When I asked in a workshop who owned it and what concrete decision or deliverable came out of it, nobody had a clear answer. It was a placeholder where work went to stall. We removed it, and across iterations we simplified the analysis stage from 16 steps down to 12. Before automating a step, ask whether it serves a real control or value purpose, or whether it is just historical handover overhead.
Second, divert simple work into deterministic fast lanes. On my first intake whiteboard, a small note in the corner read: “Product config item: out of scope.” Simple tariff updates were getting stuck inside a heavy architectural analysis stage built for complex, multi-system initiatives. We turned that exception into an express lane: standard configuration updates bypassed architectural analysis altogether and went straight to backlog refinement. In software and AI architecture, the parallel is direct: when routing follows stable, repeatable rules (if/else), plain code and APIs are faster, cheaper to run, and easier to debug than a model call.
Only after you have cut the unnecessary steps and handled deterministic routing in code do you ask where AI belongs — and even then, distinguish between a single LLM call and an agent.
Many high-friction boundaries where messy inputs meet structured systems — such as translating and categorizing a free-form support ticket against historical incidents, checking whether an incoming change request is missing required context, or summarizing logs across tools — are useful places for LLM assistance inside a predefined workflow. An agent becomes worthwhile when completing the task requires choosing what to investigate next, selecting tools, and adapting its approach as new information arrives.
For high-consequence decisions — such as cross-market billing changes or security sign-offs — I would retain explicit human approval and a named decision owner.
Explicit Boundaries Underneath, Simple Interfaces on Top
By the time our delivery process went live, the full specification covered 4 stages and 65 numbered steps, backed by a review log documenting roughly 60 stakeholder comments and 32 recorded decisions.
When you are aligning seven countries — or when you are defining the operating environment for an agentic system — explicit boundaries matter. An agent may dynamically decide how to investigate an issue or draft a response, but its permissions, validation checks, escalation triggers, and stopping conditions need to be clearly defined.
However, a 65-step specification is a reference for system builders and governance — not something a practitioner can hold in their head at 9 AM on a Monday.
Keep the complex routing and boundary logic in the underlying system specification; keep the human interface inside the daily board and on a single page.
To make our redesigned processes usable in daily work, we relied on three practices that matter just as much when rolling out AI-assisted workflows:
- Integrate into the System of Record. Asking people to consult a 30-page PDF during an incident — or asking engineers to adopt a separate standalone dashboard to interact with an agent — adds friction that slows adoption. We mapped our 4-stage, 65-step process onto the 13 Jira statuses the teams already used every day (from
DraftandInitial TriagetoReady for Analysis,Sprint Ready, andDone). A tool won't magically make a broken process work, but embedding workflow states directly into the daily system of record removes the friction of switching contexts. - Give every objection a visible receipt. When our incident process launched, one of our regional support teams pointed out that 24-hour target times for medium and low priority tickets didn’t work for groups without night on-call coverage. They were right, and we updated the SLA table to measure “business hours” for those tiers. During the delivery process review, every one of the ~60 stakeholder comments received a written decision in a shared log. When practitioners see their real operational constraints reflected in the system’s guardrails, trust goes up.
- Compress the human view to one page. Right before the 15 teams started their first sprint, I created a simplified 9-step view of the 23-step sprint stage focused only on cross-team touchpoints. And for every operational process we shipped — Incident, Planned Maintenance, Problem Management, and Delivery — we created a standardized One-Pager. Let the backend specification hold the detailed routing logic; keep the human reference simple enough to scan in two minutes.
The Folder in the Drawer
While researching that first incident management project, I found a folder on the shared drive from three years before I joined.
It contained the deliverables from an earlier Lean improvement initiative conducted for the exact same Service Desk: workshop notes, a time study, a current-state analysis, and a vision presentation. Reading through it, I realized several of the core problems I had just sorted on my sticky notes — inconsistent prioritization, underused tools, and friction in cross-country handoffs — had already been diagnosed three years earlier.
Finding that folder taught me a lasting lesson about the gap between a good diagnosis and sustained implementation. An accurate analysis is only the starting line; making a change stick requires resolving the conflicting definitions between teams, recording the decisions, simplifying the reference to a single page, and wiring the rules into the tools people open every morning.
Today, it is just as easy to produce an impressive AI strategy deck or a standalone agent demo that ends up in that same drawer.
Automation — whether through workflow software or AI agents — tends to amplify the structure underneath it. Before writing the orchestration code or tuning the prompt, pick one real workflow, walk into the room with a whiteboard marker, and ask the people doing the work: “Show me where the ticket actually stops.”
