jacobo-workflows: Jacobo Workflows: The n8n Agent Mesh That Runs a Phone Repair Business
A deep dive into how a Seville-based workflow stack routes conversations, checks inventory, parses dates, and hands off to humans without relying on one giant prompt.
- Jacobo is built as a workflow mesh, so each business task has its own specialist path instead of one overloaded prompt.
- The pricing flow protects against hallucination by turning messy customer input into structured inventory lookups before it returns a quote.
- The scheduling flow treats natural language as raw material, then converts it into strict booking data and availability checks.
- n8n works here because the problem is operational and modular, but that same modularity also makes state and observability the hard parts.
A phone repair shop does not need a chatbot in the abstract. It needs to answer customers, estimate repairs, book visits, check inventory, and hand off edge cases without slowing the counter down. That is why jacobo-workflows matters: it reads like a small operating system for a service business, not a demo of agentic flair.
The repo comes from Santiago Fernández de Valderrama Aparicio, known as @santifer, and it packages seven production n8n workflows from a live system called Jacobo. The headline number in the project notes is striking: the full assistant reportedly handled about 90 percent of customer interactions. That only makes sense if the system is designed around repeatable operations, not conversational improvisation.
Jacobo is not one bot. It is a mesh.
The architecture is the point. A central router does not try to solve every problem. It classifies intent, checks context, and dispatches the request to a specialist workflow that can do one job well: pricing, scheduling, ordering, or human escalation.
| System | Strength | Weakness | What Jacobo does differently |
|---|---|---|---|
| Single-prompt bot | Fast to prototype | Hallucinates on pricing and process | Splits work into specialist flows backed by tools |
| LangChain or CrewAI | High programmatic control | More code, more glue, more maintenance | Uses n8n as the runtime and keeps the stack visual |
| Zapier or Make | Easy automations | Less suited to nuanced AI routing | Combines automation with model-driven intent dispatch |
| Intercom or Zendesk AI | Polished support experience | Closed logic and limited ownership | Keeps the logic self-hosted and business-specific |
| Jacobo workflows | Operationally grounded and modular | Requires careful workflow design | Turns one shop’s processes into a reusable agent mesh |
That mesh shows up in the central workflow, `jacobo-chatbot-v2`. It acts like a dispatcher with memory. It remembers enough context to keep a conversation coherent, but it also makes hard decisions: is this a pricing question, a scheduling request, or something that needs a human? The business-hours logic is part of the behavior, not an afterthought.
Pricing is a retrieval problem, not a guessing game
The pricing workflow, `presupuesto-modelo.json`, is the clearest example of how the system prevents hallucinated answers. It cleans the model name, searches Airtable with fuzzy matching, parses stock state, and returns structured JSON. That means the assistant is not inventing a quote from thin air. It is asking the shop’s source of truth.
{
"model": "iPhone 13 screen",
"cleanedModel": "iphone 13 screen",
"stock": {
"available": true,
"qty": 2
},
"price": 89,
"needsHumanReview": false
}
This is the important distinction. A general chatbot can sound confident about a repair price. Jacobo is built to prove that the price exists first. If stock is missing, another workflow creates a pending order instead of pretending the part is available.
Scheduling turns messy language into a booking-ready date
The appointment sub-agent, `subagente-citas.json`, treats a phrase like "next Tuesday afternoon" as raw input, not a fact. It parses that language into a strict schema, checks availability against the booking system, and then produces a clean intent the main workflow can use. That is how a casual message becomes a real appointment request.
| Step | What the user says | What the workflow needs | Why it matters |
|---|---|---|---|
| Date parsing | "next Tuesday afternoon" | Strict date and time fields | The system can book without ambiguity |
| Availability check | A vague request | Calendar truth | The assistant avoids overpromising |
| Booking intent | A conversation fragment | Structured JSON | The main router can continue cleanly |
| Fallback | Unclear timing | Human handoff | The shop does not lose the lead |
The interesting part is that this is not a generic calendar bot. It is a specialist that knows its job inside a broader operational chain. The router decides the request belongs on the scheduling path, and the sub-agent does the translation work that humans usually do by hand.
The small tricks that make it feel human
Jacobo also uses little operational details that matter more than they sound. A wait message goes out before slower checks so customers are not left staring at silence. Discount logic is handled in code when the business rule is simpler than a model prompt. And when inventory is missing, the system can create a pending order and preserve the lead instead of dropping it.
- A wait message reduces perceived latency before slower tool calls.
- Discount rules stay deterministic in a code node instead of being left to model judgment.
- Inventory gaps can trigger a pending order, which keeps the workflow moving.
- Human handoff preserves context, so escalation does not reset the conversation.
Those details are what make the system feel like an assistant a shop could actually run. It is not trying to be witty. It is trying to be reliable, fast, and good enough to keep a customer moving toward a repair.
Why n8n works here, and where it would not
n8n is a strong fit because the problem is modular. The system needs routing, API calls, structured outputs, and human escalation, which are all natural shapes for workflow automation. It also helps that the shop can keep control of logic, data, and integrations instead of handing everything to a black-box support product.
| Option | Best at | Weakness | Jacobo's position |
|---|---|---|---|
| n8n workflows | Operational orchestration | State and observability require discipline | Uses n8n as the runtime for a production agent mesh |
| Code-first agent frameworks | Deep control and custom logic | More engineering overhead | Jacobo keeps the control plane visual and reusable |
| Support SaaS | Polished customer support | Closed logic and limited customization | Jacobo is tailored to one shop’s process |
| Single chatbot | Simple user experience | Poor fit for business operations | Jacobo decomposes the job into reliable specialists |
That trade-off is the editorial lesson. Jacobo is not a universal pattern. It is a strong answer to a narrow, high-value problem: a real business with repeatable workflows, messy inputs, and a need for human fallback. In that setting, n8n is not just glue. It is the operating layer.





