Case Study
From prompt-based API execution to reusable enterprise AI skills.
This case study summarizes how an enterprise CRM automation system evolved through multiple architecture stages and is now exploring a reusable skill-based direction for repair, dispatch, scheduling, notification, and route-planning operations.
Architecture focus
Agentic AI execution
System domain
Enterprise CRM workflows
Key direction
Reusable skill systems
Architecture
Each stage solved one set of problems while revealing the next architecture constraint.
Stage 1
Pattern
User Input → Prompt → LLM → API Call → Response
Fast PoC and MVP development
Natural-language input flexibility
Easy integration with existing APIs
Low cost to add simple capabilities
Limited stability across repeated runs
Execution order was difficult to control
Weak state tracking across long processes
Lower control over API parameters and formats
Debugging became difficult as prompts and context grew
Stage 2
Pattern
User Request → Master Agent ├─ Query Agent ├─ Validation Agent ├─ Notification Agent └─ Route Agent
High modularity
Easy to extend
Easy to reuse
Prompts are easier to maintain
Useful for splitting complex domains
More complex architecture
Higher token cost
More difficult debugging
Information can be distorted between agents
Does not naturally solve flow-control problems
Still needs workflows or state machines for long-running processes
Stage 3
Pattern
Workflow Orchestrator ├─ LLM Node ├─ Function Node ├─ API Node ├─ Condition Node └─ State Node (dynamic path based on workflow state)
High flow stability
Stronger state management
More predictable results
Easier debugging and monitoring
Supports complex business logic
Strong fit for standardized enterprise workflows
More controllable LLM cost
Higher development and setup cost
Lower flexibility when flows change
Large workflows increase maintenance complexity
Limited value for exploratory or open-ended tasks
Simple needs can become over-engineered
Stage 4 / In Progress
Pattern
Agent → Large Skill (fixed process control) → Small Skill (capability execution) → Workflow / API / LLM / JS → Standardized Result → Next Stage or CRM Operation Result
Stable flow with lower risk of skipping validation or repeating operations
Small skills can be reused across different business processes
Clear responsibility split between large skills, small skills, and workflows
Easier to modify, test, and maintain than one large workflow
Each task can choose API, LLM, JS, or workflow execution as needed
Small skills can be tested, replaced, and versioned independently
More architecture layers increase early design and decomposition cost
Large skills, small skills, and workflows need consistent input and output formats
Errors can happen across layers, making debugging more complex
Overly fine-grained skills increase skill count and management cost
Requires additional flow state, error handling, and cross-layer observability
Less flexible than fully autonomous agent planning
System Model
The current direction explores how to separate agent intent from stable execution capabilities.
Understands task intent
Exposes reusable capability
Controls execution path
Runs tools and reasoning
Completes operation
Comparison
The architecture moved from flexible but fragile prompt behavior toward reusable, controlled execution.
The important engineering shift is not adding more prompts. It is moving toward an execution architecture where agents can choose reusable capabilities, while workflows and backend services handle the deterministic parts of enterprise operations.