A language model does not become an agent merely by producing longer answers. An agent receives tools, can read state, and may trigger actions within narrow boundaries. That boundary — which data is visible, which tools are allowed, and when a person must approve — is the real core of the system.
I do not build vague “AI initiatives”, but a bounded workflow with a measurable input, outcome, and escalation path.
Anatomy of an agent workflow
- Deterministic frame: n8n, custom TypeScript/Python, or an existing workflow engine controls triggers, state, retries, and failure paths. The model is one component, not the whole workflow.
- Model layer: OpenAI, Anthropic, suitable EU providers, or locally served models through Ollama or vLLM. A routing layer can allocate tasks by quality, latency, or cost.
- Structured decisions: JSON schemas and validated structured outputs prevent free-form model text from becoming an unchecked system command.
- Tools: function calling connects the agent to approved CRM, email, calendar, ticketing, or database functions. Every call is authorised and validated server-side.
- Context: RAG, session state, and selectively loaded business data provide only the context needed for the current case.
- Control points: approvals, amount and volume limits, idempotency keys, timeouts, and a manual handoff path contain failures.
Example: support triage without autopilot
A new request enters from the ticketing system. Conventional rules check the customer, contract, and priority. The model classifies the issue, retrieves from approved knowledge sources where needed, and returns a structured response draft. Only low-risk cases can be prepared automatically; sending, credits, or account changes remain behind the defined approvals. The outcome, sources, tool calls, and handoff reason are recorded.
Evaluation and operations
- a representative test set from real, sanitised cases
- metrics for classification accuracy, valid tool calls, escalation rate, latency, and cost
- regression tests for prompt, model, and workflow changes
- per-run traces without needlessly duplicating personal data in logs
- timeouts, retries, rate limits, a fallback model, and a dead-letter path
- monitoring and alerts for technical failures and material quality shifts
Common use cases
- lead qualification with CRM lookup and structured handoff
- support triage and grounded response drafts
- document review and extraction into a fixed schema
- preparatory booking, ordering, or approval workflows
- internal research across several knowledge sources
What’s included
- define the use case, allowed actions, and measurable success criteria
- select architecture, models, and tools against real examples
- implement integrations and server-validated tool functions
- develop prompts, schemas, RAG access, and approval points
- set up the evaluation set, regression tests, tracing, and operational alerts
- document data flows, permissions, failure paths, and operations
Clear boundary
No unattended automation for decisions with legal, financial, medical, or security-critical impact. Fine-tuning is not automatically part of the project; better data, retrieval, schemas, and evaluation often create more value first.