- Departments are still necessary, but customers don't care who sits in which department. They only care when their issue will be resolved.
- Every time work is handed across departments, a queue forms and information gets lost. This is where the time really goes.
- Pick one workflow that crosses three departments, get it running end to end first, and expand after that.
1. From AI assistant to a system that takes on multi-step work
The difference between an assistant and an employee is that an assistant waits to be told what to do, one thing at a time, while an employee takes a goal and sees it through. AI is moving from the first kind to the second, and that is why the way you organize has to change with it.
An AI Assistant answers questions or produces drafts when someone asks it to. An Agent takes a goal and carries out a sequence of work: reading a request, checking data, calling an API, creating a document, requesting approval and following up. This shifts the unit of automation from “one task” to “one outcome,” and outcomes often cross systems and departments.
For the development team · Technical detail
By 2028 to 2029, companies are likely to have several types of agents, such as a Sales Agent, a Procurement Agent and a Support Agent, working alongside existing automation. Agents shouldn't be left to work everything out on their own. They should operate within the workflows, permissions and policies the organization defines.
2. Why silo structures slow a company down
A customer asking for a quotation doesn't care that the details sit with sales, the pricing with accounting and the delivery date with production. They only care when they'll get an answer. Every time work passes from one desk to another, a queue forms.
Departments were created to bring expertise together, but customer workflows don't stop at organizational lines. The customer wants a quotation and has no interest in the fact that the data sits in sales, the pricing in Finance and the delivery date in Operations. Every handoff adds a queue, room for misinterpretation and a chance for information to slip through the cracks.

Once agents can connect data, keeping handoffs on email and spreadsheets becomes the new bottleneck. AI may prepare an answer in seconds and then wait a day for an approver, or create a document that someone then has to copy into the system by hand. So the change has to reach decision rights and the workflow itself. Bolting an agent onto the old process won't do it.
That said, you shouldn't dissolve every department. Expertise, people development, professional standards and oversight are still needed. The answer is a “Functional Home + Outcome Workflow” model: people keep a home base for their expertise but work through paths with a shared owner for the outcome.
3. Organizing around workflows
For the development team · Technical metrics
Define your key value streams, such as Lead-to-Cash, Idea-to-Launch, Procure-to-Pay and Issue-to-Resolution. Each stream has an Outcome Owner who is accountable for its KPIs from start to finish and can't claim their department's part is done while the customer is still waiting.
For the development team · Technical detail
Build a digital workflow that records a central state. Each agent picks up work in response to events, and data is never passed along by copying. For example, when a lead meets the criteria, the Pricing Service is called, a draft is created and sent to the approval queue. Once it is approved, the CRM, the order and the forecast are updated in a transaction that can be traced.
| Component | Role | Owner |
|---|---|---|
| Outcome | The result the customer and the business receive | Value Stream Owner |
| Workflow | The sequence of states, rules and exceptions | Process Owner |
| Agent | Understands, creates and calls tools | Agent Sponsor |
| Data | Facts and permissions | Data Owner |
| Control | Policy, logs, risk and cost | IT/Security/Risk |
4. The role of people in an Agentic Organization
For the development team · Technical metrics
The Outcome Owner sets the KPIs and trade-offs, the Process Designer designs the straight-through, review and exception paths, the Agent Sponsor is accountable for an agent's purpose and permissions, the Domain Reviewer checks quality and the difficult cases, and the Platform Team looks after shared standards.

Team leads will spend less time dividing up queues and chasing work, and more time analyzing the causes of exceptions, refining the knowledge base and making capacity decisions. Frontline staff take the cases with the most ambiguity and the highest impact, so they need a complete summary of the information. They shouldn't be handed scraps of work the agent couldn't finish, with no context.
Mid-sized companies shouldn't create too many new positions. One person may wear several hats, but each hat has to be clearly defined, especially who is responsible when an agent uses the wrong data or acts outside its scope.
5. Build a control plane before the number of agents grows
A control plane is a central system that knows which agents exist, who sponsors each one, which model it uses, which data and tools it can access, how much it costs and how well it performs. Every agent needs its own identity and least-privilege permissions, instead of sharing an employee's account.

For the development team · Technical detail
Define policies that are enforced outside the prompt, such as no transfers above a set limit, no sending personal data to external channels, and mandatory approval before any action that is hard to reverse. Have a kill switch, rate limits, budget limits and an audit log that the operations team can actually use.
Evaluation has to be ongoing, because models, data and workflows change. Build a set of important cases, test against it before each deployment and spot-check production as well. If quality drops, the system should automatically fall back to human review instead of letting errors pile up.
6. A Lead-to-Cash example in an agentic organization
For the development team · Technical detail
A Marketing Agent receives the lead and checks consent, a Sales Agent fills in company information and sets priorities, a Solution Agent builds the proposal from the product catalog, a Pricing Service calculates the price, an approval workflow routes only the special cases, and an Order Agent creates the order once the customer confirms. Every step works from a single state and records its data sources.

People come in at the key points: sales staff make sense of vague needs, managers approve discounts and Finance checks risky customers. If an agent finds conflicting data, it must stop and summarize what it knows and what needs deciding, instead of sending a bare error message.
7. Moving away from the old departments without causing confusion
- Pick one value stream: Map the process and appoint an Outcome Owner.
- Build a central state: Stop passing status around in emails and in multiple versions of files.
- Split the tasks: Separate deterministic automation, AI judgment and human decisions.
- Trial in shadow mode: Let the agent make recommendations without taking action, and compare it with the real team.
- Open permissions one level at a time: Start with reading, then creating drafts, and only then writing or sending in standard cases.
- Adjust KPIs and roles: Drop metrics that let each department optimize for itself while the workflow as a whole stays slow.
During the transition, you need a manual procedure and an incident owner. Don't run the old and new systems side by side indefinitely, because that doubles the work. Set criteria for retiring the old steps once the new system is stable and has made it through a peak period.
8. A readiness checklist for executives
- There is an Outcome Owner and a Process Owner who can make decisions across departments
- Core systems have APIs or another secure way to connect
- Key data has a source of truth and an owner
- There is a policy on which actions agents may take
- Human approval, audit, cost control and a manual fallback are in place
- KPIs measure the value stream from start to finish
If several of these are missing, start with the process and the data foundation. Don't buy an agent platform and hope the technology will make up for the organization's lack of clarity, because the system will spread ambiguity and conflict faster than before.
In short: Agents will thin the walls between departments, but the need for expertise and accountability remains. The organization of the future should combine a functional home with outcome workflows, a central state and a control plane. Companies that start designing decision rights and data today will be able to use agents across departments without losing control.
Microsoft: AI alone won't change your business
Design cross-department workflows the system can run, with people still in control
What each of your departments knows best is the rules of its own work: which cases can be approved right away, which need a manager to look at them, and which the system must never decide. This knowledge lives in people's heads and is scattered across emails and files. DNA Maker's first job is to draw it out into something a system can read. We talk with the Outcome Owner of each value stream and write it down as a central state, the conditions for each change of status, the permissions for each role and the points where a person must approve. All of it is written in business language first, and only then turned into a technical specification.
From diagram to a system in daily use
The system that follows usually includes a workflow engine that holds one shared state for the whole line, integration with core systems through APIs, an exception queue for people, and a screen where managers can see where work is stuck and who is holding it. If agents are brought in to help, we give each one its own identity and only the permissions it needs, with an audit log that lets you trace every action. The way we recommend starting is to pick one value stream, such as Lead-to-Cash, and get it running for real before expanding. If you have a process that crosses three departments and people still track its status by phoning each other, that is a good place to start.
SOFTWARE ENGINEERING GLOSSARY
Software engineering glossary
These terms come up when you discuss systems that work across departments. Use the questions on the right to see the scope and the risks from the start.
| Term | What it is | A simple example | What executives should ask the development team |
|---|---|---|---|
| Orchestration | Defining who or which system does what, in what order, and what happens when a step fails | The system calls pricing, creates the document, then sends it for approval according to set conditions | If a step in the middle fails, what does the system do next, and who finds out? |
| Source of Truth | The authoritative data source that every system refers to | Product prices live in one system instead of in each department's own files | Where does the authoritative data live, and who owns it? |
| Exception Queue | A single queue for items the system won't decide by itself, so people only look at what they need to | A discount above the ceiling is sent to the manager's queue | Who watches this queue, and what happens if nobody looks at it within a set number of hours? |
| Least Privilege | Granting only the permissions the job needs, and no more | An agent can read customer data but cannot change prices | Which data can this system access, and when are its permissions revoked? |
| Audit Log | A record of who did what, when, and with which data | You can trace who approved this quotation | When something goes wrong, how much detail can we trace back? |
