I believe that we're on an inevitable path toward AI ubiquity in enterprise systems. Every platform will have some aspect of AI-native tooling across a variety of capacities: monitoring and observability, governance and anomaly detection, workflow orchestration, knowledge retrieval and "what if?" querying.
That doesn't mean every process will be executed by an autonomous agent. I don't think that will be the case. Most processes will involve some degree of AI involvement at a stage in their lifecycle, in the same way that most processes today involve a database query or a notification at some stage. It becomes infrastructure.
Vision Starts at the Top
AI vision has to come from an organization's leadership. That means defining expectations for how the organization will transform as AI tooling matures, and identifying a suite of hedges that span from objectives through milestones through talent through guardrails.
Not everyone in an organization will use AI in their work. Not everyone will understand it well enough to do so, and that's fine. True leadership here is ensuring that a framework exists so that the people who are developing AI agents, workflows, and solutions are delivering real value to the entire organization, and not just finding success in isolation.
Labs and Centres of Excellence
Labs or Centres of Excellence are great places for AI experimentation at work. When provided with the freedom to identify opportunities, define discrete expectations, and approach solutions in secure sandboxes with applicable guardrails, these groups can deliver high-fidelity solutions that meet leadership objectives.
Pair these individuals with teams throughout the organization. They need to appreciate the bottlenecks firsthand, acknowledge the nuance in how processes actually run (not how documentation says they run), and foster enthusiasm among the people closest to the work. That encourages organic adoption, because the solutions are grounded in real problems rather than abstract mandates.
Frame It as Time Reclaimed
I'm not naive about the reality. Most organizations and teams are swamped. There's no capacity for a 6-week AI literacy program, and there shouldn't need to be.
Not everyone will use AI in the same way. Builders will use it to help them build, managers will use it to spend more time reviewing and coaching, and analysts will use it to spend more time on interpretation instead of data wrangling. Embracing AI as a tool that lets you do more of the work you actually want to do is the right framing. Pretty often, that translates directly to ROI, because the highest-value work a person does is the work they're best at and most engaged with.
It should absolutely not be a competition to see who can burn the most tokens or who comes up with the most suggestions. That kind of gamification produces noise, not outcomes. A better approach is to pair individuals who don't use AI much with individuals who do. The goal is exposure through collaboration, not a leaderboard.
The Right Questions Have Structure
The organizations with successful, durable AI programs will be the ones who understood their own processes well enough to know where AI was useful and where it wasn't. That understanding starts with asking better framed questions.
Here are real questions I've heard in conversations with HR leaders and consultants:
"Are there any AI tools that are better for HR to use?"
"How do I use AI to improve our new hire onboarding process?"
"How do I get my team to use AI more?"
These aren't unreasonable questions. They also don't define deliverables. They're the AI equivalent of asking "how should we use electricity?"
Good AI questions share 4 components. With my clients, I've developed the following PSDE Framework: Process, Specifics, Data, and Evaluation.
Process: Identify each process for consideration. "New hire onboarding for our home care nurses, which processes 40 new hires per quarter".
Specifics: Quantify the bottleneck with discrete metrics: time costs, error rates, manual steps, handoff delays. For example, "each new hire requires 14 manual tasks across 4 systems and takes an average of 6 hours of coordinator time."
Data: Map the data dependencies for each step: data sources, format, sensitivity, access and regulatory requirements. The precision of the data map directly affects the quality of any technical recommendation.
Evaluation: Define evaluation criteria that measure whether the process succeeded. If success criteria can't be articulated explicitly, success is difficult to qualify and therefore easy to hallucinate.
Every question should touch at least 2 of these. The best questions touch all 4.
Rewriting the Question
Consider the question "How do I get my team to use AI more?"
This question frames adoption as the objective. It shouldn't be. The objective is improving specific processes. Adoption is a byproduct of doing that well.
Through the PSDE framework, we can generate a well-defined problem statement that directly translates to solution and tooling identification:
"Our benefits team spends about 30% of their time on two things during open enrollment. First, answering the same 15 questions from employees about plan options, eligibility, and deadlines. We've documented the questions and the correct answers. Second, collecting and verifying dependent documentation: birth certificates, marriage certificates, and legal guardianship records. A coordinator manually reviews each uploaded document, confirms it contains the required information, checks that names and dates match the enrollment submission, and flags anything incomplete or inconsistent. Between the two, the team loses about 200 hours per enrollment window. Can we surface repeatable questions with repeatable answers automatically, route special cases to a human, handle some of the document review programmatically, and track resolution time to measure whether we're actually reducing the coordinator workload? What do we need to be careful about with PII?"
The rewrite replaces the adoption question with two use cases. It includes the volume, the current process for document verification, the desired behavior, evaluation criteria, and the compliance concern.
It also surfaces the tool diversity that a good decomposition reveals. The Q&A maps to deterministic retrieval: documented questions with documented answers, routed by topic. The document verification involves both structured extraction (names, dates, and document types from uploaded files) and linguistic reasoning (interpreting whether a legal guardianship document satisfies the dependent eligibility criteria). The coordinator review stays human for judgment and safety. Each step maps to a different tool type.
Adoption is organic when the tool is pointed at a real problem that the team already cares about, provides reliable results, and can be scheduled for automatic engagement during predictable windows like open enrollment.
A Practical Strategy: Process Decomposition
The following approach is scalable.
Step 1: Collect process decomposition worksheets. Distribute a short-form worksheet to employees that asks two questions: "What's something you think takes up too much of your time?" and "What do you think can be improved in how this process works?" The form should take no more than 5 minutes to complete.
These serve a dual purpose. They surface real process bottlenecks from the people closest to the work, and they function as first drafts of Standard Operating Procedures (which has value regardless of whether these progress).
Step 2: Mine existing operational data. Compile all completed support tickets, incident reports, or service requests from the last quarter. Identify frequent issues, group them by time to complete and by team. Cross-reference the results against the process decomposition submissions. The overlap between what employees report as painful and what the data confirms as painful is where the highest-confidence opportunities are. LLMs can help with a lot of this work.
Step 3: Decompose the top candidates. Break the highest-priority processes into granular steps. For each step, identify the inputs, outputs, policies and rules, approving authority, and success criteria.
Step 4: Evaluate each step for improvement. With a decomposed process in front of the team, the question becomes precise: "Can any of these steps be improved with new approaches?" From there, cycle through options with specificity.
Evaluate whether the step can be handled by a configurable workflow with deterministic routing or a rules engine with conditional logic. If so, the step is a candidate for automation rather than AI.
Determine whether the step requires detecting patterns, categories, or anomalies, and whether those patterns are numerical (thresholds, distributions, outlier detection) or linguistic (interpreting unstructured text, classifying intent, extracting meaning from documents). Language models are probabilistic systems that excel at tasks requiring interpretation of ambiguous, unstructured content, for example, reading a free-text expense report description like "client dinner with team, parking, and cab back to hotel" and determining that it contains three separate line items spanning two budget categories. For deterministic tasks like verifying that a document contains exactly 5 required sections, dedicated validation tools are more reliable. Matching the tool to the task type ensures that the system is reliable and repeatable.
Assess the cost of failure. High-impact errors warrant engineering safeguards and human-in-the-loop checkpoints. Low-impact errors may be acceptable with periodic review.
This decomposition makes the opportunities visible. It also makes the non-opportunities visible, which is equally valuable, because it prevents teams from spending 3 months building an AI solution for a problem that could've been solved with a dropdown menu and a webhook.
The discipline also transfers. Decomposing a process into its inputs, outputs, policies, judgment calls, and success criteria is useful whether the solution involves AI, deterministic automation, or a manual redesign.
Experimenting Safely at Scale
AI Labs and Centres of Excellence should have permission to prototype against real process decompositions, but within defined boundaries: scoped data access, defined escalation paths, and clear ownership of what gets promoted to production and what stays experimental.
The operating principle is sandboxed autonomy. The experimentation team builds freely in isolated, secure environments without waiting on approvals to prototype. A RACI structure governs the boundary between experimentation and production: the process owner (typically the team lead or department head) owns the problem definition, success criteria, and output validation, while a designated AI initiative lead owns technical scoping and implementation decisions. IT, security, and legal engage just-in-time, specifically when the team requires access to production data, when permissions to integrated systems are needed, or when a prototype is ready for evaluation before promotion. That separation preserves the speed of experimentation while respecting safety.
Guardrail design for AI workflows is an active area of research, and one I plan to cover in a dedicated article next week: how to construct guardrails that are precise enough to prevent real harm but flexible enough to sustain useful experimentation.
The 5-Minute Process Decomposition Worksheet
The following worksheet decomposes a process into the components required for scoping any improvement, whether AI-driven or otherwise.
- Process Name: What do you call this task or workflow?
- Frequency: Daily, weekly, monthly, per event.
- Time Cost: Time per occurrence; number of people involved.
- Steps: List each end-to-end step with enough detail to hand off to someone unfamiliar with the process.
- Inputs: Describe the data, documents, and source systems each step requires.
- Judgment Calls: Describe the steps that require human decision-making based on experience, context, or policy interpretation.
- Policies: List the regulations, company policies, or compliance requirements that constrain the process.
- Success Criteria: Define how correctness is measured for the completed process.
- Pain Points: Identify the steps with the highest time cost, error rate, or rework.
A completed worksheet provides a technical team with sufficient detail to map each step to an architecture decision: deterministic automation, AI reasoning, human judgment, or process redesign.
Geoffrey Momin is a software engineer with over a decade of experience building integrations and applied AI systems for enterprise customers. This is the second in a series of articles on the intersection of AI, context graphs, and enterprise systems of record.