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.

9 min read • View on GitHub • More from santifer

A tiny repair-shop command center with one central desk routing incoming customer tickets into separate channels for pricing, booking, stock checks, and human handoff. The scene explains that Jacobo behaves like an operations system, not a single chatbot.
Jacobo’s core idea is operational, not conversational. One message enters, specialized workflows do the work, and the business gets a usable answer back.
Key Takeaways

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.

This decision tree is the project’s real mental model. One customer message enters, the router decides what kind of work is needed, and a specialist workflow resolves it with the right data source.

SystemStrengthWeaknessWhat Jacobo does differently
Single-prompt botFast to prototypeHallucinates on pricing and processSplits work into specialist flows backed by tools
LangChain or CrewAIHigh programmatic controlMore code, more glue, more maintenanceUses n8n as the runtime and keeps the stack visual
Zapier or MakeEasy automationsLess suited to nuanced AI routingCombines automation with model-driven intent dispatch
Intercom or Zendesk AIPolished support experienceClosed logic and limited ownershipKeeps the logic self-hosted and business-specific
Jacobo workflowsOperationally grounded and modularRequires careful workflow designTurns 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.

A crumpled repair note on the left is transformed into a neat structured order card on the right. The image explains how Jacobo cleans noisy human language, matches it against inventory and price data, and avoids guessing.
Pricing is where the system becomes careful. Human language comes in messy, but the workflow returns structured data instead of a guess.

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.

StepWhat the user saysWhat the workflow needsWhy it matters
Date parsing"next Tuesday afternoon"Strict date and time fieldsThe system can book without ambiguity
Availability checkA vague requestCalendar truthThe assistant avoids overpromising
Booking intentA conversation fragmentStructured JSONThe main router can continue cleanly
FallbackUnclear timingHuman handoffThe 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.

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.

OptionBest atWeaknessJacobo's position
n8n workflowsOperational orchestrationState and observability require disciplineUses n8n as the runtime for a production agent mesh
Code-first agent frameworksDeep control and custom logicMore engineering overheadJacobo keeps the control plane visual and reusable
Support SaaSPolished customer supportClosed logic and limited customizationJacobo is tailored to one shop’s process
Single chatbotSimple user experiencePoor fit for business operationsJacobo 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.