Questions the company has already answered
Staff or customers asking what the policy says, what the product does, how a ticket was resolved. The system returns the passage with its source, or says the corpus does not contain the answer.
AI integration
The model answers from your records, calls a short list of tools, and stops where a person has to decide.
We put that in place for one workflow, in accounts you own, and leave you with the tests that show when it is wrong.
- Retrieval with sources
- Agent guidance
- Tool protocols
- Approval on writes
- Evaluation set
The first workflow
One piece of work that already costs time every week.
The conversation starts by naming it and the systems it touches. These are the shapes it usually takes.
A draft, held for a person
A reply, a renewal, a summary prepared from the account record and the last contract. It waits until a person reads it and sends it.
A back-office check
An invoice against a subscription, a ticket against a known defect. The system lists the mismatch. It does not fix the books by itself.
A technical engagement
Three parts, in this order.
The same shape as every engagement here, for a system instead of a channel. The site describes the shape and leaves commercial terms to the written design.
First
A written design.
Before anything is built. It names the workflow, the systems of record, the corpus, the tools and their side effects, where each class of data sits, which model product is called, what that product retains, and the evaluation set that will decide whether a change ships.
Then
The build of that one system.
In your cloud and your source accounts. Instructions are versioned. Tools are allow-listed. The evaluation set runs against real questions with known answers. A short operating note tells your people what the system will do and who to tell when it is wrong.
After launch
Support of the named system.
A new workflow is new work: specified, designed, and accepted on its own. It is not absorbed into the retainer. You own the system at the end of the build: the account, the index, the instructions, the evaluation set, and the runbook.
Retrieval
A named corpus. A few passages. A source on every answer.
A corpus is a chosen set of documents with an owner, a date, and a permission on each. The system retrieves the passages that matter and asks the model to answer from those, or to say that it cannot.
01
The corpus is a list
These folders, these ticket views, these tables. Named in the design, with what is excluded named as well.
02
Answer from passages, with the source attached
The model is given a few relevant passages and asked to answer from them. When the corpus does not contain the answer, it says so. Both behaviors are in the evaluation set.
03
Hybrid search when the corpus earns it
A lexical match beside an embedding match, when the corpus is large enough that wording and meaning both matter. A reranker is added when the first results are noisy and the evaluation set shows it. A small, clean corpus often needs neither.
04
Freshness is part of the build
An index that lags the source is a defect. The refresh schedule matches how often that source changes.
Agent guidance
An instruction set a person can read and predict.
Guidance is a versioned document, reviewed like code, and it is what you own at the end rather than a workshop.
What the instruction set contains
- The job, in a few sentences
- The sources the agent may use
- The cases it refuses, including questions the corpus does not answer
- The tool list, each tool marked read, draft, or write
- The stop condition, and the point at which a person takes over
- The shape of the output
What that buys you
Behavior that is known before launch.
Changes to the instructions ship only when the evaluation set still passes. Your people get a one-page operating note: what it will do, what it will not do, who to tell when it is wrong.
Tool protocols
A tool is a named operation with a schema. The model never holds the keys.
Only the tools the caller is allowed
The server offers a caller the tools that caller’s authorization allows, and no others. Credentials stay on the server that performs the call. The model sees arguments and results.
Read, draft, write
Read tools run inside the caller’s scope. Draft tools produce something a person sends. Write tools, which change a record, send mail, post, or pay, wait for an explicit approval on that action.
The Model Context Protocol, in one sentence
A way to describe a tool so a model can call it without holding the keys. We use it when more than one client should call the same tool, or when your environment already speaks it. A single product calling its own API needs an OpenAPI description and a small authenticated adapter, which is the same discipline. Agent-to-agent protocols solve a different problem and are not the first system at this size.
The evaluation set is the gate.A failed set blocks the change. It lives in your project.
Evaluation
Questions from the real workflow, with answers a person has checked.
The set covers questions the corpus can answer, questions it cannot, and questions the agent must refuse. It is stored with the system, in your project. It runs before a model change, an instruction change, or a meaningful change to the corpus ships. When it fails, nothing ships.
Document text is treated as untrusted input. A passage can try to widen the agent’s instructions. It cannot widen the tool list, the credentials, or the approval rule, because those live outside the prompt.
Where the model is called
A bounded context goes to the model. The corpus stays home.
At request time
The call carries the retrieved passages and the tool results for that question. It does not carry the corpus, and it does not carry credentials. Traffic is encrypted in transit; the index is encrypted at rest with your cloud controls.
When your data cannot accept a vendor’s default retention
The design chooses a path that carries the constraint: an approved zero-retention arrangement on an eligible endpoint, or a model hosted inside your own cloud account. If neither is available, that data is not sent.
Questions
About AI integration.
If yours is not here, ask.
What does “one workflow” mean?
A piece of work that already costs the company time every week, with the systems it touches named: a question your people answer from policies and tickets, a draft prepared from the account record, a back-office check that lists a mismatch. The first conversation names it. The design is written against it.
Will the model make things up?
It answers from the passages it retrieved, with the source attached, or it says the corpus does not contain the answer. The evaluation set includes questions the corpus cannot answer, so that refusal is tested rather than assumed.
Can the agent send mail or change a record?
Only through a tool classed as a write, and only after a person approves that action. Read tools run inside the caller’s own permissions. Draft tools produce something a person sends. Nothing leaves the building on the model’s say-so.
Do we need the Model Context Protocol?
If more than one client should call the same tool, or your environment already speaks it, yes. A single product calling its own HTTP API does not need a protocol conversion for its own sake; an OpenAPI description and a small authenticated adapter are the same discipline. Agent-to-agent protocols solve a different problem and are not the first system at this size.
Which model do you use?
The one the design names, called through a commercial API or hosted in your own cloud account. The choice follows the data rule rather than the demo. The design records what that product retains and what we do if your data cannot accept it.
What do we own at the end?
The account, the index, the instruction set, the evaluation set, and the runbook. Our access is named, time-bounded, and removed when the engagement pauses.