Designing a support agent on the canvas

A support agent is really a small system: it takes a customer message, figures out what is being asked, finds the right answer in your material, and responds in a way your team is comfortable with. In cove1 you build that system on a visual canvas, connecting steps into a flow you can see and reason about, without writing code.

The canvas matters because support logic is full of decisions, and decisions are much easier to trust when you can look at them.

The canvas: a flow you can see

Each agent is a graph of nodes on the canvas. A node might classify an incoming message, retrieve from your knowledge base, call the model to draft a reply, apply a guardrail, or route the conversation somewhere. You connect nodes to describe how a conversation should move from question to answer.

Because the flow is visual, the people who actually know your support process can shape it. A support lead can see that billing questions take one path and technical questions take another, and can change that path by rearranging nodes rather than filing a ticket with engineering. What the agent does is legible, which means it is reviewable.

The knowledge base: your answers, indexed

An agent is only as good as what it knows. In cove1 you build a knowledge base from your own material: help center articles, product documentation, policies, past answers, and internal guides. cove1 indexes that content so the agent can search it by meaning rather than exact keywords.

This is the difference between an agent that improvises and one that is grounded. When a customer asks about your refund window, the agent should answer from your refund policy, not from a plausible-sounding guess. The knowledge base is what makes the answer come from you.

Retrieval with sources

When the agent answers, a retrieval step pulls the most relevant passages from your knowledge base and passes them to the model as the basis for the reply. Crucially, cove1 keeps track of which passages were used, so answers can carry their sources.

That has two payoffs:

For customers, answers can cite where they came from, which builds trust and lets people verify.
For your team, every answer is traceable. When something is wrong, you can see whether the agent retrieved the wrong passage or the source itself is out of date, and fix the actual cause.

Grounding answers in retrieved, cited passages is also the main defense against confident-but-wrong replies. The agent is steered toward what your documents actually say.

Building without code

Putting these together is a matter of assembly, not programming. A typical support agent on the canvas looks like this:

Receive the message from a connected channel.
Classify intent so you can branch by topic.
Retrieve relevant passages from the knowledge base.
Draft a grounded reply with the model, keeping sources.
Check confidence and either send or hand off.

Every one of these is a node you configure, not a function you write. You can test the flow, watch how a real question moves through it, and adjust.

Iterating in the open

Support is never finished. Products ship, policies change, and customers ask things you did not anticipate. Because the agent is a visible flow over a knowledge base you own, improving it is ordinary work: add a document, adjust a branch, tighten a guardrail. How you write and split those documents is what decides whether retrieval finds them — see knowledge base software for AI support. The canvas keeps the whole system in view. For a worked vertical example, see the property management answering service, or to see a sample flow, reach us at gan@jincove.com.