Gideon — One core, seven agents, your business on autopilot
Seven AI agents —finance, legal, accounting, operations, marketing, design and engineering— that talk to each other to sell, charge and run your business inside WhatsApp. On web, desktop and mobile.
Constraints
- Several companies sharing one platform demand strict isolation, not convention.
- Per-customer memory has to work without the customer waiting for the system to think twice.
- The card number cannot exist on our servers, and each company charges with its own account.
- WhatsApp imposes its 24-hour window and template rules, not the other way around.
- The business has to feel the agent is theirs without the platform losing the channel to update it.
The problem
Seven agents, one brain
When a customer messages you, it is not a bot answering: it is a team.
Gideon is a core of specialised AI agents that talk to each other. Each one covers an area of the business and all of them share the same customer memory, so the second agent already knows what the first one said.
- Finance
- Legal
- Accounting
- Operations
- Marketing
- Design
- Engineering
One core · seven agents · shared memory
A complete sale nobody touches
This is what a real customer closing a purchase inside WhatsApp looks like. Five agents, forty seconds, zero human intervention.
Query → stock → payment → charge → invoice
That is the point of the product: the conversation channel stops being support and becomes sales. Every message is a conscious operation, not a reply.
Where your operation lives
It is not a single-channel chatbot. It is the same core wherever your customer and your team already are.
- WhatsApp The main channel. Every company connects its own number.
- Web Panel, catalogue and conversations in sync, nothing to install.
- Desktop Native app for macOS, Windows and Linux, with notifications.
- Mobile Answer, approve and monitor from the phone.
One core, every channel
Who it is for
- Telco
- Retail
- MNO / MVNO
- E-commerce
- Fintech
- Logistics
- Health
Three concrete scenarios, of the kind of operation it was built for:
A telecom. Handles plan and top-up queries 24/7 with no queue, and escalates to a human only when needed. The agent checks the balance, offers the plan that fits and charges in the same thread.
An e-commerce store. Recovers carts and takes orders from the web and from messaging. The cart lives in the conversation, payment opens in a secure checkout, and the receipt arrives on WhatsApp.
A clinic. Books appointments and sends reminders with no intervention. The patient reschedules from the same chat and the practice sees the full history before they arrive.
From zero to a productive agent in three steps
- 01 Connect Your WhatsApp number, your catalogue, your customer system. A guided integration instead of a traumatic migration.
- 02 Orchestrate The core assembles each customer's context and the agents answer with executable actions: quote, charge, book, escalate.
- 03 Scale The agent stores memory and updates context in real time. When it should not handle something alone, it escalates to a human with the whole context assembled.
What you see in your panel
The product does not only answer: it measures. These are the four figures Gideon puts in front of you and updates with every conversation.
- Chat conversion Out of how many conversations a sale comes out.
- Response time How long the agent takes to resolve, human excluded.
- Repeat sales Customers who buy again through the same channel.
- Resolved without a human What share closes without escalating to a person.
The four panel metrics, not marketing promises
Plans
- Pilot Validate $0 MXN / month 1 to 2 pilot companies, no upfront cost. To test the minimal loop before committing to anything.
- Recommended Business $5,999 MXN / month The complete service: agents, catalogue, payments, panel and human escalation.
- Enterprise Custom Quoted Dedicated infrastructure, your own integrations and reinforced isolation.
Under the hood: why it holds up
A commercial product breaks when it grows if the decisions underneath do not hold. Three you cannot see from the demo:
- Companies and users
- Agents and blueprints
- Products, orders and charges
- Memory and follow-up
- Assembles the context
- Keeps no state
- No access to the data
- Returns text or actions
- Switching models is swapping a piece
What decides cannot leak what it knows
The brain has no access to the data. Because it only receives context, it cannot leak information from one company to another, and “the agent remembers wrong” becomes “the context arrived badly assembled” — something that reproduces and gets fixed without querying the model again.
Isolation between companies is a rule of the system, not a convention. Each company has its agents, its memory and its charges separated, on one platform.
The desktop authenticates as a device, not as a user. It activates from another trusted device, the key can be revoked with its reason recorded, and a security incident log is kept. A key the user copies and pastes does not survive them sharing a screenshot.
And there is a whole product line around it: plans, per-company permissions, signed module versions and device control. That is what separates an application from a platform.
About the team
Gideon is mine: I founded it and lead it inside Alean. The architecture, the data model, the core design and the platform decisions are my design; the implementation goes through pull-request review.
Decisions
- 01
What decides the answer has no access to the data
The engine that reasons and writes the reply does not query the business's information: it receives an already-assembled context —customer profile, conversation summary, recent thread and the available actions— and returns text or an action. All truth lives in the system; the reasoning lives apart.
RejectedGiving the engine direct access to the information. It multiplies the places where one company's data can leak into another's, and ties the model's lifecycle to the platform's.
- 02
What the agent remembers is a design decision, not the model's
Because the engine queries nothing, the context is its only input. That turns "the agent remembers wrong" into "the context arrived badly assembled": a problem that reproduces and gets fixed without calling the model again, and without burning tokens to find the cause.
- 03
Blueprints resolve in cascade, they do not fork
An agent is no longer a record with a free-text field. There is a catalogue of vertical blueprints and the effective configuration resolves in layers: platform, blueprint, company, agent. The business overrides whatever it wants and feels the agent as theirs; the platform keeps the channel to update it.
RejectedLetting the customer fork the blueprint. It sounds more flexible and it means that by the second update that customer is stuck on a frozen version nobody touches again.
- 04
Memory is split by scope, not accumulated in the thread
Customer facts live per company and customer, shared across every agent in that company. The live thread is per agent and customer, capped, with a summary that actually fits in the context. They are three different things, and mixing them ends in conversations that grow until the agent stops understanding.
- 05
Fact extraction and summaries never block the response
The memory work runs in the background with the cheapest model. The agent answers with what it already knows and memory catches up afterwards. It is the difference between replying in a second and replying in four because the system is thinking about its own file.
- 06
The desktop authenticates as a device, not with a pasted token
The desktop client does not ask the user to copy a key. It activates through the standard device-authorization flow: the activation is born pending and with no user attached, it is approved from another trusted device, and the key left on the machine can be revoked with its reason recorded. There is verification that the device is who it claims to be, and a security incident log.
RejectedA key the user copies and pastes. Faster to build, and it does not survive them sharing a screenshot.
- 07
The desktop module is a product line, with strict separation
What started as an internal tool ended up as a product: identity per company, plans, permissions and signed modules on the same platform. Mixing two businesses in one system is a real cost; the mitigation was not splitting it in two —that would have left it undelivered— but isolating it with discipline so extracting it later is cheap.
- 08
Declaring what the system will NOT do
The non-goals are written down: no voice or telephony, no third-party blueprint marketplace, no forking by the customer, no visual prompt editor with arbitrary blocks. A project without non-goals has no limits, and a system without limits does not get finished.
Outcome
- Seven specialised agents —finance, legal, accounting, operations, marketing, design and engineering— with real-time handoff and shared memory.
- A single WhatsApp conversation resolves query, stock, payment link, charge and invoice with no human intervention.
- A desktop client that activates as a device, with plans, permissions, signed versions and revocation.
- Every company connects its own WhatsApp, with its own data, its own memory and its own charges isolated from the rest.
- A catalogue of vertical blueprints with per-company adjustments, without anyone getting stuck on a frozen version of the platform.