Liaison

The problem

Every new hire, intern, or team transfer hits the same wall: they have a question and don’t know who to ask. Is it answered in a doc somewhere? Is it for my manager, HR, legal, or the person who built the system? So they guess, ping the wrong person, or don’t ask at all.

The same problem shows up with customers. Companies that sell life-science products (DNA extraction kits, reagents, lab instruments) get hundreds of customer questions a week, and the new employees fielding them face it at its sharpest. Most questions are already answered in a datasheet or protocol. A few are dangerous. “Can I use this on patient samples?” about a Research Use Only product, “Is yours better than Qiagen’s?”, or “What’s next year’s price?” can each turn into an off-label claim, a regulatory finding, or a pricing leak if someone answers carelessly. A new hire usually can’t tell which is which.

So these companies keep a person in the loop for almost every question, internal or external. The question gets forwarded to an expert, the expert answers in a thread, and the answer stays there. Next month a different employee or customer asks the same thing and the process starts over.

What we’re building: an AI agent that gives new employees a trusted first stop for “who do I ask?” It answers documented questions with citations to the source, flags sensitive ones (regulatory, pricing, competitive, HR, confidential) and routes them to the right expert instead of guessing, and turns each expert reply into approved, reusable knowledge so the next person gets an instant answer. Along the way, it helps new hires learn who owns what and what they need to know to ramp into their role.

What this looks like today

Here's the same question going through a typical support inbox:

Monday: a customer asks whether the kit works with FFPE tissue. Support forwards it to R&D, R&D loops in the one scientist who knows, and the customer gets an answer on Thursday.

Friday, 5 pm: a customer asks whether they can use the kit's results to confirm a named patient's diagnosis. A tired rep replies "should be fine." That one email combines a Research Use Only product, a clinical use and patient data in a single thread.

Three weeks later: a different customer asks the same FFPE question, and support asks R&D again: "has anyone answered this before?"

Why company chatbots don't solve it

Companies already have support chatbots and internal Q&A tools like RAG bots, Glean or Intercom, and they work well for easy, documented questions. Liaison is built for the questions that matter most, whether a customer or a new hire is asking:

the risky ones
the ones the documents can't answer
the ones that keep coming back

	Company chatbots	Liaison
Risky questions	Answer whatever a document passage seems to support, or refuse too broadly	Tells risky from routine. Liaison can tell "What are your support hours?" from "Is this approved for clinical use?", and "Where's the PTO policy?" from "Can I share next year's pricing with a partner?" A Compliance Guard checks every question and every answer against six regulated risk categories, and checks that every claim is backed by a cited source. Routine answers go out right away; risky ones go to a human. It never approves by default.
Questions the docs can't answer	"Sorry, I don't know," or a guess	Keeps going when the documents run out. Liaison sends the question to the specific expert who knows, chosen by their role and their real work (GitHub commits and PRs), and asks them directly in Slack. The person asking gets an answer from a real expert, not a dead end.
The next time someone asks	Nothing has changed	Gets smarter with every answer. The Guard checks the expert's answer, Liaison stores it, and the next person gets it instantly, even if they word the question differently. Experts answer each question once.
Where it lives	One more widget or portal	Works where people already are. Employees use Slack and customers use ASI:One. There's no custom frontend and no new tool to adopt.

Chatbots answer from your documents. Liaison also learns from your experts, and it's built for companies where one wrong answer is a liability.

Our solution

Liaison is a network of three Fetch.ai agents:

Vendor Agent (hosted on Agentverse, reachable through ASI:One with the Chat Protocol). It answers from the company's own documents and cites them. It checks its learned knowledge base first. If that has no match, it retrieves passages, writes a draft and sends the draft to the Guard.
Compliance Guard (hosted on Agentverse). It screens every question and every outgoing answer for against the company’s policy pack: patient data, clinical use of an RUO product, off-label use, comparative claims, pricing/contracts and roadmap. Deterministic rules run first, then an LLM judge, then a grounding check that every claim in a draft is supported by the cited text. If a rule matches, that verdict is final, and the judge can only make a verdict stricter.
Router (a Slack bot, /ask). When the documents can't answer a question, it proposes the expert most likely to know. The asker approves, the expert replies in the Slack thread, and the Guard checks the reply.

The learning loop: an approved expert answer is saved to the knowledge base, and the next person who asks the same question, even worded differently, gets the answer in seconds with no escalation.

Case study: Lumen Biosciences

Lumen Biosciences is a fictional company modeled on a typical life-science vendor (all of its documents are synthetic). Lumen sells the AuroraPrep RUO Nucleic Acid Extraction Kit, which purifies DNA and RNA from tissue, cells and plasma. The kit is labeled For Research Use Only, so anything suggesting it can be used to diagnose patients is off-limits.

Lumen has three experts: Saanvi (R&D: extraction chemistry, yield, protocols), Neha (Quality/Regulatory, plus pricing and contracts) and Manasvini (Engineering, plus orders and shipping).

Here's how each group at Lumen uses Liaison:

Customers ask on ASI:One at any hour. "What's the shelf life of an unopened kit?" gets a cited answer from the datasheet in seconds.
Risky questions are stopped before anything goes out. The John Smith diagnosis question is blocked as patient data plus clinical use of an RUO product, and the reason is shown.
Unknown questions go to the right person. "Does it work with FFPE?" isn't in the docs, so Liaison suggests Saanvi in Slack. She answers once, and the Guard approves her answer.
The next asker gets the answer instantly. A different customer asks the FFPE question in different words and gets Saanvi's approved answer right away.
Compliance gets a Guard that also checks the experts' own answers, so the knowledge base stays clean as it grows.

How we built it

Contract first. Before writing any agent code we froze the message schemas in contracts/: GuardRequest/GuardVerdict, Escalation, ApprovedAnswer, IngestDocument. That let three of us build three agents in parallel.
uAgents + Agentverse. The Vendor Agent and the Guard run as hosted agents. The Router runs locally as a mailbox agent connected to Slack through Socket Mode. Every hop uses the Chat Protocol and the shared contracts.
Gemini drafts the answers, provides embeddings for retrieval and the knowledge base, and powers the Guard's LLM judge.
Matching uses cosine similarity. A new question reuses a learned answer only if

$$\cos(\mathbf{q}, \mathbf{k}) = \frac{\mathbf{q}\cdot\mathbf{k}}{\lVert\mathbf{q}\rVert\,\lVert\mathbf{k}\rVert} \ge 0.85$$

Expert matching uses a looser threshold of 0.35, and commit and PR evidence is weighted at 0.9× a profile line.

Trust rules. The Guard only accepts messages from allowlisted agent addresses. The Vendor Agent only stores an ApprovedAnswer if it comes from the trusted Router and matches a pending escalation. Only allowlisted experts can approve answers.
A labeled eval with a strict bar. We required 100% recall in every blocker category and at least 80% overall precision. On 53 labeled rows with the real Gemini judge, the Guard scored 100% recall and 100% precision in every category. The full test suite runs offline.

Challenges we ran into

Hosted Agentverse limits. We wrote a throwaway probe agent to find out what the hosted runtime allows. It runs Python 3.10, doesn't support folders or data files, and has no __file__. It also loads modules in a way that breaks dataclasses under from __future__ import annotations. We added a build step that flattens each agent into one directory, rewrites the imports, embeds the policy file as Python, and has its own test that runs the flat build in a separate interpreter.
Dependencies in the hosted environment. We replaced the Gemini SDK with plain REST calls using only the standard library, so the agents run on Agentverse without extra packages.
A 10-second answer budget. A draft needs a judge call and a grounding call within 10 s, so each LLM call has its own timeout. If the judge is unavailable, the Guard fails closed and marks the answer needs_review instead of approving it.
Rate limits and billing. On the free tier, HTTP 429s counted as "judge unavailable" and failed eval runs. Prepaid billing with a $0 balance returned 402 and did not fall back to the free tier.

What we learned

An LLM can be used safely in a compliance path when rule hits are final, the model can only make verdicts stricter, and any failure goes to human review.
In a regulated domain, recall per category matters more than overall accuracy. One off-label answer getting through costs more than ten cautious "let me check with an expert" replies.
Freezing the interfaces before writing code was the best decision we made for a three-person hackathon build.
Before building on a platform, write a small probe to find out what it actually allows.

What's next

Following up in ASI:One when an expert answers after the customer has left the chat
Adding documents by dropping files in Slack
Marking learned answers stale when their source document changes
Hiding expert names from external askers, and giving each knowledge-base entry an audience (internal or external)