One entry point, one defined path. The conversation stays flexible while the execution behind it stays the same. Illustration generated with OpenAI.
The AI-Native Company · Part 2 of 5
Enterprise AI is moving closer to the systems where work actually happens. In September 2026, Business Insider reported that Accenture and Google Cloud were organizing 1,000 forward-deployed engineers to help clients embed AI agents into operations. That scale of implementation effort is revealing. An assistant can be useful on its own, but completing business work requires access, context and decisions about how existing processes should run. The integration work is becoming part of the product.
The problem appears in an ordinary request: “Prepare the monthly client report.” A person understands that this involves the right account, reporting period, source data, calculations, commentary and review. An assistant may understand the language while still lacking the right execution path. Give it broad tool access and it may improvise steps that should be... consistent. Make the employee move to a separate workflow application, and you introduce another handoff. The design question is how to preserve a convenient conversation while making the underlying work dependable.
Small errors can become significant when several steps depend on one another. As an illustration, if ten necessary steps each succeed independently 98% of the time, the probability that all ten succeed is about 82%. Real workflows do not satisfy that simple independence assumption, and retries or checks can improve outcomes. The calculation is useful, because it exposes the weakness of measuring only the final answer’s appearance. A report can read well while using the wrong date range, duplicating a transaction or reaching the wrong recipient. The resulting cost sits in correction, investigation and lost trust.
Three arrangements cover most of what teams actually build. Allow an assistant to select and use individual tools. Offer a dedicated workflow through a form or application. Or let the assistant recognize an appropriate request and invoke that workflow on the person’s behalf.
Each has a legitimate use. The choice depends on how much the path varies, how reliably the intended action can be identified and what happens when the system gets it wrong. Hybrid routing is particularly useful when the request is conversational but the outcome is familiar.
- Direct tool use gives the assistant flexibility. It can investigate an unusual account, gather information from several places and adapt as it learns. That is useful when the correct sequence cannot be specified in advance. It also leaves more operational decisions with the model. I would expose narrowly defined tools, restrict their permissions and require evidence of completed actions. Where a business rule matters, such as an authorized spending limit, the executing system should check it. A reminder in a prompt is an instruction to follow, with different properties from an enforced limit.
- A dedicated workflow offers clarity. A form can require a client, reporting period and delivery scope before anything starts. People can see what the process will produce and who approves it. This is often the best interface for a frequent, structured task. Its limitation is the effort required to find and learn another application, especially when the work begins inside an ongoing conversation. Keep the form available even in a hybrid design: it provides a clear alternative when a request is difficult to interpret.
- The hybrid design connects the two. The assistant identifies the outcome, gathers missing inputs and invokes an approved workflow with the user’s permitted scope. The workflow retrieves the data, runs its checks, prepares the deliverable and returns a result or a specific exception. “Prepare” can authorize a draft while “send” requires separate authority. The employee can remain in the conversation throughout. Implementation details may stay out of view, but the distinction between a suggestion and a completed action must remain clear.
Anthropic’s engineering guidance recommends “finding the simplest solution possible” and describes routing inputs to specialized tasks as a common pattern. That is a useful check against turning every interaction into an elaborate agent system. A conversational layer is worthwhile when it reduces effort or handles meaningful variation; it can also make a simple task less predictable. If someone enters the same three fields every Friday, a scheduled workflow or a saved form may serve them better. The interface should justify its own cost.
An operations leader and the team responsible for business systems can pilot this on a single request with a clear outcome.
- Document its accepted inputs, allowed actions, approval requirements and failure conditions.
- Test paraphrases, missing information, unauthorized requests and attempts to send when only drafting was requested.
- Measure incorrect routing separately from failures inside the workflow.
- Return a plain-language receipt stating what completed, what changed and what still needs attention.
- Use the same execution rules regardless of whether the request arrives through chat, a form or an API.
The gain here is lower coordination effort around one consistent process. Employees spend less time finding tools, re-entering context and moving results between systems. The company gains a reusable execution method that can improve centrally. I would measure request-to-accepted-outcome time, review effort, routing errors and cost per completed case. Those measures also expose when the hybrid layer is unnecessary. Its success should appear in the work completed, rather than the number of conversations it attracts.
The next issue addresses the discovery problem behind this design. Which recurring requests deserve a shared workflow in the first place? Many of the best candidates may already exist as personal methods inside employee AI accounts. Finding them requires a way to surface useful practices and test their value without treating private conversations as company inventory.
Florian Boymond is the founder and CEO of Stackmint, focused on turning enterprise expertise into dependable AI operations.
The AI-Native Company series
- Part 1: Top-down vs. bottom-up AI: what are we actually changing?
- Part 3: Your next AI workflow may already exist in someone's personal account
Originally published on LinkedIn on 2026-09-24.
