Agents here mean models that call tools: look up an order, open a ticket, query 1C through an agreed API, or talk to an IDE via Model Context Protocol. This is not process optimization (routing forms without an agent loop) and not RAG (retrieve text). It is a controlled loop with budgets, timeouts, and a human stop button.
MCP servers expose tools with schemas, auth, and logs. I implement servers your team can run next to Cursor, Claude Desktop, or an internal agent runtime—not a toy “20 tools, no allowlist.” Prompt injection and tool abuse are first-class: see MCP in production and agentic engineering. Spend and routing belong on LLM gateway and eval.
A realistic first phase is two or three tools on one workflow: e.g. “status of order X” plus “create a support ticket with the transcript.” Multi-agent graphs that debate each other look good in talks and fail in support queues. I will refuse a scope that cannot name the tools and the blast radius.
Stack: TypeScript for MCP and most web tools, Python when the existing ML/OCR contour is already Python. ERP writes go through contracts on ERP integration or 1C—never ad-hoc SQL from a prompt. Related deliveries: cursor-telegram-integration (agent-style tooling in a messenger) and thinklens-bot.
Handoff includes tool schemas, env secrets, rate limits, and a kill switch. Out of scope: unsupervised agents with production write access on day one, or “autonomous company OS” pitches.
Timeline: a thin MCP + one messenger or CLI adapter is often 4–8 weeks after API credentials exist.
What you get
- Tool inventory, allowlist, and failure modes in writing
- MCP or equivalent tool server, auth, structured logs
- Eval of tool-choice and argument correctness, not only chat fluency
- Hypercare: stuck loops, retries, and operator runbook
