The models are capable enough to transform a large amount of enterprise work. The harder problem is turning that intelligence into a system a company can trust, operate, and improve.
A conversation with Decagon's founders makes the distinction unusually clear. Decagon began with customer-support agents, but the deeper product was a system for following business processes: connecting to company systems, applying changing procedures, testing behavior, monitoring outcomes, and improving from real interactions.
- 01
Use frontier models to discover. Specialize after the workflow is proven.
The fastest way to test a new use case is usually the most capable available model. Once the workflow is stable and running at scale, repeatable tasks can move to smaller, faster, and more controllable models. Prove value first; specialize second.
- 02
Treat model choice as routing—not religion.
No enterprise needs one model for every job. Bounded, high-volume execution may belong on task-specific models; open-ended analysis, experimentation, and improvement may still require frontier intelligence. Use the right intelligence at the right point in the workflow.
- 03
Own the evaluations before you try to own the models.
Fine-tuning is not the starting point. First define what good performance means for your work. Public benchmarks cannot determine whether a rebooking, regulated conversation, or escalation was handled correctly. Proprietary evaluations are the operating truth of an enterprise AI system.
- 04
Evaluate the whole workflow—not one model call.
A model can perform its individual task correctly while the business process still fails. Test the complete journey: decision, tool use, policy compliance, handoff, completion, recovery, and the actual customer and business outcome.
- 05
Keep changing business rules outside the model weights.
Stable behavior can be trained into a model. Frequently changing procedures should live in a readable, editable runtime layer: policies, permissions, approval gates, integrations, and operating procedures. A policy change should not become a retraining project.
- 06
Productize every lesson from the field.
Each deployment should leave behind something reusable: a connector, evaluation set, policy control, deployment pattern, monitoring rule, or recovery procedure. When the next customer benefits from the previous deployment, fieldwork becomes compounding product development.
- 07
Build a glass box—not a vendor-controlled black box.
Business and technical owners need to see what the system is doing, understand why it acted, test changes, and update approved procedures. If every diagnosis and improvement must pass through the vendor, the customer cannot scale. Enterprise control is a product advantage.
- 08
Build the system that improves the system.
The most important agent may be the slower supervisory system reviewing thousands of interactions, finding repeated failures, proposing better procedures, and generating new tests. Execution creates experience; experience should create evaluations; evaluations should create approved improvements.
- 09
Sell the path to production—not access to AI.
Enterprises must move through security, model risk, compliance, testing, and rollout without losing control. The deployment method is part of the product: staged release, production monitoring, issue correction, and prevention of recurrence.
- 10
Land on one workflow. Expand on the business-process primitive.
Start with one or two high-value workflows whose pain is visible and outcomes are measurable. Prove the operating model, then expand into adjacent work that can reuse the same context, controls, integrations, and evaluations.
THE CIO OPPORTUNITY
Choose the workflow—not the model.
The strategic question is no longer, “Which model should we standardize on?” It is: Which workflow can we make measurable, controllable, and progressively better?
Production Advantage = Proprietary Evaluations × Workflow Control × Iteration Speed
Start with the work that can compound
Choose a workflow with a measurable outcome, changing business rules, and enough repetition to create useful operating experience. Own its evaluations, keep its controls editable, and turn every failure and correction into an approved system improvement.
That is how an agent becomes an enterprise learning system.