Every enterprise I talk to is stuck in the same trap. On one side: Legacy automation. BPMN workflows. Scripts. Integration platforms. Safe, auditable, reliable—and impossibly slow to build. Your team spends months mapping a single process. The backlog grows. Only the top 1% of use cases ever get automated.
On the other side: Agentic AI. The promise is intoxicating. “Just let the AI figure it out.” No more mapping. No more coding. The agent reasons, acts, and solves problems on the fly.
But here’s what the demos don’t show you: Agents drift.
An agent might solve a problem one way today and a completely different way tomorrow. It might skip steps. Hallucinate tools that don’t exist. Route a refund to the CEO’s inbox because it seemed helpful. And when your auditor asks “why did the system do that?”—good luck explaining that the AI “felt like it.”
The paradox of enterprise automation: Safe is slow. Fast is dangerous.
I’ve been developing an architectural pattern that resolves this paradox. I call it Governed Dynamism—and it might change how you think about AI in the enterprise.
The Cowpath Principle: Let Users Show You the Way
In urban planning, there’s a concept called “desire paths.”
Instead of deciding where people should walk and pouring concrete, smart planners do something counterintuitive: they plant grass and wait.
Over time, people trample natural paths through the grass—the routes they actually want to take. These are called “cowpaths.” Once the paths are visible, the planners pave them.
Governed Dynamism applies this principle to software automation:
| Phase | Urban Planning | Enterprise AI |
|---|---|---|
| The Grass | Unpaved field | Dynamic Mode—AI explores unknown problems |
| The Path | Trampled trail | The Trace—recorded sequence of successful actions |
| The Pavement | Concrete sidewalk | Deterministic Mode—rigid, immutable workflow |
The insight is simple but profound:
Use AI as a temporary pioneer, not a permanent worker
You pay the “AI tax”—the latency, cost, and risk of non-deterministic reasoning—during a discovery phase. The AI might try different approaches. Some will fail. Some will succeed but take suboptimal paths. Over multiple executions, patterns emerge: which tool sequences work, which ones perform best, which ones handle edge cases gracefully.
Once you have enough successful traces to identify a reliable pattern, you pave it. Then every future execution is instant, cheap, and fully auditable.
How Governed Dynamism Works: The Three Phases
Phase 1: Discovery (The Pioneer)
When a user asks for something new—something with no existing workflow—the system enters Dynamic Mode.
An AI agent is given a “bag of tools” and a goal. It reasons through the problem step by step:
-
“I need to look up the user.” → Calls get_user
-
“Now I need to check their order status.” → Calls check_order
-
“The order is delivered. I can process the refund.” → Calls stripe_refund
But here’s the critical difference from a typical agent framework: every action passes through a governance layer.
Before stripe_refund executes, the system asks: - Does this user have permission to trigger refunds? - Does this specific refund exceed policy limits? - Does this action require human approval?
If the action is flagged, execution pauses. A human reviews and approves (or rejects). The AI doesn’t get to “just do things.”
Meanwhile, the system is quietly recording everything: what tools were called, in what order, with what parameters, and why the AI made each decision.
This recording is called the trace.
Phase 2: Promotion (The Builder)
If we stopped at Phase 1, we’d just be another agent framework with guardrails. Phase 2 is where the magic happens.
After the system observes enough successful traces—dozens of users requesting refunds, each one recorded—a pattern emerges:
get_user → check_order_status → stripe_refund
The system analyzes these traces and asks: C_an we pave this cowpath?_
It generates a workflow definition—a rigid, deterministic sequence of steps with explicit data mappings. No AI decision-making in the loop. Just code.
A human engineer reviews the generated definition. They see that the logic is sound, the edge cases are covered, and the governance rules are baked in. They click “Approve.”
The cowpath is now a highway.
Phase 3: Operations (The Settler)
The next time a user asks to “refund Alice’s order,” something different happens.
The system recognizes the intent. Instead of spinning up an AI agent, it:
- Uses a lightweight LLM call only to extract parameters (“Alice,” “order #12345”)
- Executes the pre-defined workflow deterministically
- Returns the result in milliseconds
No reasoning. No tool selection. No drift.
The performance difference:
| Metric | Dynamic Mode | Deterministic Mode |
|---|---|---|
| Latency(p50) | 8,500 ms | 180 ms |
| Cost per execution | $0.15 | $0.008 |
| Audit complexity | High (review AI reasoning) | Trivial (fixed path) |
You’ve automated the creation of automation.
Constrained Intelligence: AI as Sensor, Not Driver
A common objection: “Doesn’t ‘deterministic’ mean ‘no AI’? Aren’t we giving up flexibility?”
No. And this is the most misunderstood part.
We eliminate AI from the control flow—deciding what to do next. But we often keep AI in the data flow—understanding messy inputs.
I call this Constrained Intelligence.
The Problem: Messy Data
A support ticket arrives as free-form text:
“I’ve been waiting 3 weeks for my refund and nobody is helping me. This is ridiculous. Order #12345.”
You need to: 1. Extract the order number → “12345” 2. Detect the sentiment → Angry 3. Categorize the issue → Billing 4. Route to the right queue → Urgent Billing
**Pure code can’t do this. ** Regex can find “Order #12345” but can’t determine that the customer is angry, or that “refund” means this is a billing issue rather than a technical issue.
Pure agents are dangerous. Give an AI agent the full task, and it might decide: “This seems really urgent, I’ll escalate directly to the CEO.” It invented a path that doesn’t exist.
The Solution: AI for Understanding, Code for Control
**Constrained Intelligence separates these concerns: **
Step 1 (AI): "Read this ticket. Output: sentiment (1-10), category (BILLING/TECHNICAL/SALES/OTHER)"
↓ AI outputs: { sentiment: 2, category: "BILLING" } ↓ Schema validation: Is sentiment an integer 1-10? Is category in the allowed list?
Step 2 (Code):
IF category == "BILLING" AND sentiment < 4 → Urgent Billing Queue
ELSE IF category == "TECHNICAL" → Tech Queue
ELSE → General Queue
The constraint: The AI must output data matching a strict schema. If it returns category: "CEO_ESCALATION", the engine rejects it before routing happens. The AI cannot invent new categories. The AI cannot decide which queue exists. The AI cannot skip the sentiment analysis.
**AI provides understanding. Code provides control. **
Think of it this way: in a pure agent system, the AI is the driver—it can steer anywhere, including off a cliff. In Constrained Intelligence, the AI is a sensor—it tells you what’s happening, but the steering wheel is bolted to the workflow definition.
The Intent vs. Implementation Problem
Here’s a pattern that took months to articulate, and it might save you from a class of bugs you didn’t know you had.
LLMs should express intent. Systems should handle implementation
Consider this scenario: After every purchase, you send the buyer a gift. The gift order goes to one of two vendors: - Orders ≤ $500 → Vendor A - Orders > $500 → Vendor B
The naive approach: Give the AI two tools (send_gift_vendor_a, send_gift_vendor_b) and explain the policy in the prompt.
What happens:
AI sees: [send_gift_vendor_a, send_gift_vendor_b] AI thinks: "I need to send a gift. I'll use vendor_a." AI calls: send_gift_vendor_a(amount=700)
Result: Wrong vendor. Business logic error.
The AI has access to both tools. The policy exists in the prompt, but: - Maybe the AI ignored it - Maybe it misread the threshold - Maybe it hallucinated a reason why Vendor A was appropriate.
**This isn’t a permission problem. It’s a category error. ** The vendor choice is an implementation detail governed by business policy. The AI should express intent (“send a gift”), not implementation (“use Vendor B”).
The Fix: Separate Intent from Implementation
| Category | LLM Decides? | Example |
|---|---|---|
| What to do | Yes | "Send a gift" |
| How to do it | No | "Use Vendor B" |
| Whether allowed | No | “Amount within limit?” |
Expose a single send_gift tool. The system handles vendor routing internally, based on policy. The AI can’t choose wrong because it can’t see the choice.
The beauty of Governed Dynamism: Even if you do expose both vendor tools during discovery, the traces will reveal the pattern. The paving process will extract the rule (if amount > 500 → vendor_b) and make it deterministic.
You don’t have to know all your business rules upfront. The system discovers them through observation and codifies them automatically.
What This Looks Like at Scale
Day 1: The system is purely dynamic. AI agents solve novel problems with high cost and strict per-step governance. Every action is logged.
Day 30: The most common problems (“the head”) have been identified. Their traces are analyzed, parameterized, and promoted to approved workflows. Cost per transaction drops.
Day 100: The system is predominantly deterministic. 95%+ of traffic runs on paved highways—fast, cheap, and fully auditable. The AI planner sits ready to handle only the newest, rarest edge cases (“the tail”).
The Knowledge Graph isn’t a static database anymore. It’s a learning engine.
Every interaction makes the system smarter. Every resolved edge case becomes a candidate for the next paved workflow. The organization captures institutional knowledge automatically, in executable form.
The Three Guarantees
-
Safety Every action—dynamic or deterministic—passes through a governance layer. Permissions, policies, and approvals are enforced consistently. The AI cannot bypass controls.
-
Efficiency You pay the AI tax during discovery—multiple executions while the system learns what works. But once a pattern is paved, future executions cost 95% less and run 50x faster. The more you use the system, the cheaper it gets.
-
Evolution The system learns from usage. Business rules emerge from observation. The backlog of “processes we should automate” shrinks automatically because automation writes itself.
The Shift in Market
The industry has been asking the wrong question.
Wrong question: “How do we make agents safe enough for production?”
This leads to guardrails, filters, sandboxes—all trying to contain something fundamentally unpredictable. You’re fighting the nature of agents.
Better question: “How do we use agents to build things that are production-ready by design?”
This reframes the AI agent from a permanent worker (unpredictable, expensive, hard to audit) to a temporary pioneer (explores the unknown, records what works, then gets out of the way).
It’s not “agents vs. workflows.” It’s agents becoming workflows.
The cowpath becomes the highway.
Getting Started: Three Steps This Week
If this resonates, here are three things you can do this week:
1. Audit Your Agent’s Decisions
Pick one AI workflow in your org. Can you explain why it made each choice? If not, you have a drift problem.
2. Identify Your Cowpaths
What are the 5 most common requests your agents handle? These are candidates for paving. Even manual conversion to deterministic workflows will cut cost and risk.
3. Separate Intent from Implementation
Review your tool design. Are you exposing implementation choices (which vendor, which API, which queue) that should be policy-driven? Consolidate them.
Technical Deep Dive
_For architects and engineers who want the implementation details. _
Workflow Lifecycle States
Every workflow exists in one of six explicit states:
DRAFT → DYNAMIC → CANDIDATE → REVIEW → APPROVED → DEPRECATED
This provides full audit trails, enables rollback, and makes promotion trackable.
Multi-Trace Convergence
A single trace only captures one path. The system requires multiple traces before promotion:
| Requirement | Purpose |
|---|---|
| Minimum 10+ traces | Statistical significance |
| 3+ unique paths | Branch coverage |
| Happy path covered | Failures handled |
| Error path covered | Core flow works |
| Edge cases observed | Robustness verified |
Parameter Synthesis
Converting traces to workflows requires classifying each parameter:
| Type | Example | Handling |
|---|---|---|
| Direct Input | User’s email | ${workflow.input.email} |
| Chained Reference | Transaction ID from Step 1 | ${steps.step1.output.id} |
| Computed Value | order_total * 0.8 | Preserve as expression |
| Implicit Context | Currency from locale | Make explicit |
Intent Routing
| Confidence | Action |
|---|---|
| Below 0.50 | Dynamic Mode (no match found) |
| 0.50 - 0.85 | Clarification (“Did you mean X or Y?”) |
| Above 0.85 | Deterministic execution |
Governance Shield (Two-Stage)
Stage 1: Visibility (Before LLM sees tools) Filter tool bag by user role and permissions. LLM only sees tools it’s allowed to use.
Stage 2: Policy (Before execution) Validate parameters against policies: - Amount limits - Time restrictions
- Rate limits - Approval requirements
Policy Types
| Type | Question | Example |
|---|---|---|
| PERMISSION | Can this user invoke this tool at all? | “Only finance team can process refunds” |
| VISIBILITY | Should the LLM even see this tool? | “Hide admin tools from support agents” |
| POLICY | Is this specific invocation allowed? | “Refund amount must be ≤ user’s limit” |
| APPROVAL | Does this need human sign-off? | “Refunds > $500 need manager approval” |
| RATE_LIMIT | Has usage threshold been exceeded? | “Max 20 refunds per user per day” |
| TIME_RESTRICTION | Is this allowed right now? | “Financial ops only during business hours” |
The Paving Formula
Discovered Traces
- Convergence Analysis
- Parameter Synthesis
- Human Review
= Deterministic Workflow
The system captures what worked, identifies patterns, generalizes parameters, and requires approval before promotion.
Conclusion
The future of enterprise AI isn’t autonomous agents running wild. It’s governed systems that learn, codify, and scale institutional knowledge.
It’s not about replacing humans. It’s about capturing human judgment once and executing it perfectly forever.
The cowpath becomes the highway.
Frequently Asked Questions
How is this different from regular workflow automation?
Traditional workflow automation requires humans to define every step upfront. Governed Dynamism lets AI discover the steps, then converts those discoveries into traditional workflows. You get the flexibility of agents during exploration and the reliability of deterministic systems in production.
What if the AI discovers a bad pattern?
Every promoted workflow goes through human review. The system shows the traces, the extracted logic, and the proposed definition. A human must approve before any cowpath becomes a highway.
How many traces do you need before paving?
It depends on complexity. Simple linear flows might need 10-20 traces. Flows with multiple branches might need 50+. The system tracks coverage metrics and won’t propose promotion until minimum thresholds are met.
Can I manually create workflows too?
Yes. Governed Dynamism doesn’t replace manual workflow authoring—it augments it. You can create workflows from scratch, or start with AI discovery and refine the result.
What about workflows that should stay dynamic?
Some tasks are inherently creative or exploratory. You can mark certain intents as “always dynamic” so they never get paved. The AI handles them every time, with full governance.
Have questions about implementing Governed Dynamism? Contact us or leave a comment below.
