A recurring question with a known source
The answer lives in a system you already run. We assess whether a defined lookup gives an assistant enough to answer reliably, and what it can't answer.
The right records, with limits
AI integrations
An assistant is only as good as what it can look up. We connect assistants to specific business systems for specific tasks, read only by default, with a person checking the result, so your team gets answers from your records rather than confident guesses.
Ask an assistant about stock and it needs the right product record and today's availability. Ask it to draft an order update and it needs the right order, with current fields. The engineering is in the connection between those records and the answer, and in making sure a partial result looks partial rather than polished.
We build that connection around one task at a time. Selected business data, a small set of defined tools, and a workflow that prepares something for a person to review. We agree what the assistant can see, how results get checked and where a human decides before considering broader access or changes to records.
Sounds familiar?
Where an assistant earns its keep
It’s rarely the grand use case. It’s the question someone answers by hand every Tuesday.
An answer that takes three lookups and a paragraph
A product, a company, an order and a written explanation. A scoped workflow gathers the records and drafts the response, with the sources and open questions still visible.
You’ve heard of MCP and want to try it on something real
Model Context Protocol lets compatible assistants call defined tools. We look at tool scope, authentication and the client you intend to use, then test whether it does the job.
What you get
A small connection you can check
A task with a checkable answer
The question, who asks it, which records it needs and what a good answer contains. Worked examples so you can judge results, and an explicit place for “the data can’t answer that”.
A limited data interface
Defined operations with defined inputs and outputs. Read only to start. Permissions, account boundaries and returned fields decided together and tied to the task.
Answers that admit their limits
Tool responses identify missing fields, pagination and truncation. We test whether the assistant preserves those limits, including ambiguous identifiers and unavailable records.
Human review, in the real setup
Where a person checks a draft, resolves doubt or approves an action. Tested with the assistant, account and connection you’ll actually use. Anything that changes records gets its own scope and its own review.
How it goes
One question. Then decide
Widening access is a separate decision, made after you’ve seen real results.
Choose the question
A real task, the records that answer it, who may use it, and what “correct and complete enough” looks like to a person.
Connect a small scope and test it
Tools and authentication built or assessed. Supported requests, partial responses and failures tested in the intended assistant, with access limited to the agreed task.
Judge it before widening it
Results against source records and the original criteria. Then refine, expand or stop. New permissions and actions are assessed separately, every time.
Common questions
Before we start
Will this work in Claude or ChatGPT?
We check the actual combination: assistant, plan, authentication and tools. MCP support on its own doesn't guarantee a given client or plan can use a given connection.
Will it change our records?
Not unless we explicitly agree it should. Read only is the default. Writes need their own permissions, review points and testing.
Can we test before committing to a project?
Yes. One question and a limited set of records is the right size. You’ll see whether it helps and what’s still unresolved.
What should we prepare?
The task, the source system, the answer or draft you want, which assistant you use and who will check the output.
Work directly with Chris
Let’s pick the question
The task, the source system, and which assistant you use.