An architecture becomes useful only when people can build, operate, and improve it together. This is the operating rhythm I would use to move from an executive objective to working AI capabilities inside departments.
The sequence is about participation and accountability: how leadership establishes direction, how teams describe their work, how one function earns a place in production, and how improvements return to the people who own the system. The companion deployment methodology covers the artifacts and readiness gates in more technical detail.
Begin with executive alignment
I would start with the leaders accountable for the scope of the initiative. Everyone reads the current charter independently before discussion. A short period of private reflection helps preserve disagreement that might otherwise disappear when the first confident voice speaks.
Each leader states the outcome their part of the business cares about. The group then has to resolve how those outcomes fit together. “More profit” needs unpacking: revenue growth, margin, cash flow, and debt reduction can imply different priorities and different constraints.
The resulting charter should explain the destination, the organization’s position, why its strategy is plausible, and what acceptable progress looks like. It should also name the unresolved tradeoffs and who owns them.
My notes suggest several days of independent review before reconvening. The exact interval is less important than giving leaders time to find contradictions before the initiative becomes a public commitment. Governance as the objective function explains the reasoning behind this starting point.
Explain the purpose to the people doing the work
The company-wide conversation should connect the initiative to the charter. What is the organization trying to do? Why does this work matter? What will teams be asked to help describe, test, and change?
My aim is to free attention for judgment, but I would not communicate that as a guarantee that nobody’s role will change. Employees need an honest account of the intended changes, how their input will be used, and where decisions remain open.
Disagreement may remain silent unless leaders make room for it. Someone who knows where the process actually breaks may also be the person least comfortable contradicting a polished demonstration. That knowledge is essential to the build.
The central commitment is that departments help define their own work. The people closest to a function are best placed to explain its exceptions, dependencies, and quality standards.
Create a fan-out and fan-in cadence
I imagine a recurring rhythm between team working sessions and leadership review. Teams explore their own functions, bring back findings, and test proposed changes. Leaders compare the maps, resolve cross-department dependencies, and return decisions to the teams.
A Friday team session followed by a Tuesday leadership meeting is one possible cadence from my notes. It is an example, not a required calendar. The important property is that local discovery and organizational alignment keep informing one another.
Directors and functional leaders have two standing responsibilities. They must track the human side of the change: confusion, frustration, adoption, and whether people feel able to challenge the system. They must also test whether each function still serves the charter.
A fast-moving team can drift away from the objective just as easily as an automated workflow can. The cadence creates a place to catch that drift before it becomes architecture.
A recurring conversation between levels
- Executive alignmentMake outcomes, tradeoffs, and decision rights explicit.
- Team discoveryPractitioners explain the actual work and its exceptions.
- Leadership reviewResolve cross-team dependencies and conflicting objectives.
- Team experimentsTest the decision in a bounded function.
Results, confusion, adoption, and disagreement feed the next leadership review.
Map the functions with the team
Ask each department to list the major functions it performs. Find a level of detail that exposes recurring structure without pretending that every instance is identical. Even highly customized work may share intake, evidence gathering, review, and handoff stages.
Take the map back to the practitioners. They should validate completeness, explain what the simple description misses, and identify where the same activity has different meanings for different customers or situations.
My starting questions for prioritization are how automatable a function is, how much human judgment it needs, and how painful the current process is. Add the evidence needed to assess impact, data readiness, and implementation risk. A painful process can deserve attention without being ready for automation.
Choose one bounded initial target. It should be important enough to teach something, narrow enough to evaluate, and supported by people who can recognize a good result. The purpose is to create a dependable learning cycle before expanding the scope.
Build against an explicit function definition
For the chosen function, specify the required inputs, tools, steps, outputs, and acceptance criteria. Test whether the available data and tools can actually produce the intended result. If they cannot, the gap belongs in the plan rather than inside an agent’s guess.
I favor building collaboratively with the department. A builder can help translate the work into an executable structure while the people who perform it explain the exceptions and review the results. That shared understanding matters as much as the initial implementation.
The technical environment should provide appropriate identity, access, tool permissions, and audit records. A private deployment is a location choice; it does not by itself settle who may see or change each piece of information.
Role-level context can then be combined with individual preferences. Rather than assuming permission to ingest an entire inbox, I would begin with approved examples and explicit questions about tone, responsibilities, and priorities. The person should be able to inspect and correct the resulting profile.
One bounded function becomes a learning cycle
- MapRecord the current inputs, work, outputs, and pain.
- SelectCheck value, judgment needs, data readiness, and risk.
- DefineAgree on inputs, outputs, tools, and acceptance criteria.
- Build togetherPractitioners supply context; builders make it executable.
- EvaluateCompare actual results with the agreed outcome.
Use corrections to improve the function before expanding its scope.
Make the interface a place for decisions
The interface I imagine gives a person a view of their active work, the functions they can invoke, the items waiting for judgment, and the actions already completed. Voice may be a useful way to ask for work or explain a correction, but it is one interface option.
A review item should arrive with the relevant evidence and the specific decision needed. A completed item should remain inspectable through its record. Monitoring can flag anomalies, but its output also needs a responsible reviewer and an understandable escalation path.
The goal is to reduce the effort of finding what matters. It is not to hide everything that an agent failed to flag. The amount of routine review should reflect the task’s consequences and the system’s measured behavior.
Keep feedback close to the work
When a person changes an output, capture both the correction and the reason. A short explanation can reveal whether the issue was factual, contextual, stylistic, or outside the system’s authority.
Human feedback and monitoring signals should accumulate into patterns that a manager or designated owner can review. Repeated missing context may change an input schema. Repeated corrections may suggest a new standard. A recurring exception may reveal that the original function boundary was wrong.
I would keep personal preferences separate from department-wide rules. Even a local refinement needs a visible record and a way to reverse it. Durable changes should be evaluated and approved before they become the default for everyone.
Connect departments through their interfaces
Once functions work dependably, some of their handoffs can become explicit interfaces. Each department publishes what it can perform for others, the required inputs, expected outputs, service expectations, and failure behavior.
That is the Role Programming Interface. A customer success function can request a billing calculation without composing an ambiguous email and waiting for several rounds of clarification. The payload carries the necessary context, while a person handles a discount or commitment outside the system’s authority.
This does not require putting every department into a single database. It requires clear ownership, authorized access, shared meanings at the boundary, and an implementation that enforces them. The output of one function can then become an event for the next.
Connect departments through a decision boundary
- Requesting functionSends the account context and the calculation needed.
- Published contractDefines required fields, permissions, outputs, and failures.
- Owning functionCalculates the result; escalates a discount outside its authority.
- Usable handoffReturns an approved result or an explicit unresolved decision.
The direction I want the organization to move
I describe roles as containing operational work, execution, and strategic judgment. The aspiration is to reduce the avoidable burden in the first two so that people can spend more attention on the third.
The result will not be a workplace where nothing ever needs supervision. It should be a workplace where the system makes its work easier to understand, corrections easier to apply, and important decisions easier to recognize.
That is why the cadence continues after launch. A functioning system needs owners who can question its assumptions, hear from the people using it, and revise it as the organization changes.
Adapted for this notebook from my AI Enterprise Implementation Framework.
The complete essay series ↗