Flagship project
Hoardy: one living picture of every customer
One place for the latest truth about every customer, built from Slack, email, Confluence, Jira and meetings without anyone typing notes. Preparing for an important call takes minutes instead of an hour.
Problem
What a vendor knows about its customers is spread across chat threads, shared mailboxes, tickets, meeting calls and people’s heads. Account context lives with individuals, so every handover, escalation and renewal starts with a cold read. Nobody has a current, trustworthy view of a customer’s health, open risks and commitments. Searching means keyword searches in five tools. Keeping a CRM or wiki up to date is the first thing people drop when they are busy.
The cost lands hardest on management. Before a renewal, an escalation or a call with a customer’s executive, a director spends the better part of an hour piecing the story together: scrolling channels, searching mail, opening tickets and asking colleagues what happened last week. Then walks into the call still unsure whether the picture is current.
And for a security vendor, pasting customer data into a public AI tool is not an option.
Approach
Hoardy watches the places the team already works and builds the customer knowledge base by itself. Nobody has to write anything down twice, and there is one place to look for the latest truth about any customer.
-
Prepares you for the call in minutes. Open the customer’s one-pager, or ask “what changed with this customer since our last call?”, and get the current state, open risks, commitments and recent sentiment, each with a link to where it came from.
-
Captures without manual entry. Watchers read Slack channels, shared mailboxes, Confluence and Jira. Documents can be uploaded, other systems send notes through an API, and approved Teams meetings become notes too: eight sources in all.
-
Turns raw text into knowledge. Each message is rewritten into clear prose, classified, scored for sentiment and importance, and linked to related notes in a single LLM call.
-
Puts it on the right customer. The model suggests a customer, a match against known names and aliases confirms it, and anything below a confidence threshold goes to a person to review instead of being guessed.
-
Keeps a living one-pager per customer. A summary rewrites itself as new evidence arrives, with a history and a before/after view of every change, a health score and a sentiment trend.
-
Answers questions in plain language. The same assistant works in the web app and in Slack direct messages: ask about a customer, edit what it knows, or create tasks.
-
Turns knowledge into work. A commitment or risk becomes a task on that customer, with reminders, projects and a timeline.
How it is built
Privacy is part of the design, not a setting. Everything runs on the company’s own infrastructure: its own Postgres database and its own model gateway (a self-hosted LiteLLM proxy), which is the only path to a model provider. A written rule forbids sending customer data, or anything derived from it, to any public third-party service.
A coordinator and nine specialists. A supervisor agent holds no domain logic of its own. It routes each request to one of nine expert agents (notes, customers, documents, tasks, operations and others), each allowed only its own tools. The experts run on a cheaper model by default and can be switched to a stronger one individually, at runtime. That keeps costs down and keeps each agent inside its boundary.
One set of business rules behind two interfaces. The logic lives once, in a shared service layer. The web assistant and the Slack bot are thin layers over it, and written rules keep the two identical.
A person decides when the machine is unsure. Assigning a note to a customer, extracting people and linking notes all have thresholds. Below them, items wait in a review queue instead of being guessed.
Auditable and tunable. Every LLM call and every error is logged, and every change to a one-pager is kept with what it replaced. Thresholds, search weights and model choices reload from the database within 30 seconds, so the pipeline can be retuned without a restart.
Python and FastAPI on the back end, LangGraph for the agents, MCP for the tools, React 19 and TypeScript in the browser, Postgres with pgvector for search, Microsoft Entra ID for sign-in with role-based permissions, all shipped as one Docker image.
What it is worth: an illustration
The figures below are an illustration, not measured results: deliberately modest assumptions, to show how the return is built. Put in your own numbers.
Five managers (account directors, heads of customer success, executives), each with two important customer calls a week: renewals, escalations, quarterly reviews. Preparing one takes about 40 minutes of searching and asking around today, and about 15 minutes with Hoardy, because a good manager still reads before a call. An account handover takes a day less, four times a year. Management time costs €90 an hour; models and hosting €400 a month.
| Per year | |
|---|---|
| Important calls prepared | 460 |
| Hours saved on call preparation | 192 |
| Hours saved on account handovers | 32 |
| Value of management time saved | €20,130 |
| Models and hosting | €4,800 |
| Net value | €15,330 |
About 50 minutes a week back for each manager, and roughly three euros back for every euro it costs to run. Not a headline number, and not the main reason to have it. The one-time cost of building it is not included, and the saving is freed-up capacity: it becomes money only when managers spend the time on customers instead of on searching.
What the table leaves out
Most of the value is not in money:
- Decisions made on the latest truth. Everyone looks at the same, current picture of the customer, not at whatever they last remember or happened to see in a channel.
- Knowledge that does not leave with people. When an account manager is ill, on holiday or leaves the company, the history of the customer stays. Nobody depends on one person’s memory.
- Customers who do not have to repeat themselves. A new contact on your side already knows the open issues and what was promised, and the customer notices.
- Problems seen early. A slide in sentiment or a risk mentioned in passing shows up on the one-pager before it turns into an escalation.
- Fewer interruptions. Colleagues are no longer asked “what is the status with this customer?” several times a week.
Result
Hoardy has been in use for more than a year, covering more than 50 existing customers, corporate and banking-grade. About 25 people use it regularly: mostly managers and team leads, plus customer-facing roles such as project managers and sales. It quickly became the first place they went for information about a customer. Instead of scrolling channels or asking colleagues, they asked Hoardy. Every request is logged, so the change can be measured, and most requests were exactly the two jobs it was built for: a summary of a customer’s current status, and preparation for a call with them.
It is a working platform, not a prototype:
| Sources it reads from | 8 |
| Expert agents | 9 |
It was built with AI coding agents as the method, not as a shortcut: specifications written before code, rules every change must follow (both interfaces kept identical, every error logged, release notes on every user-facing change) and reviewed output.
Have a process like this?
The first consultation is free. Then you get an offer that shows what the automation will cost and how much it should save.
Tell me about it
Next project Contract review that checks what is missing25 real contract drafts checked against 10 polished ones