An internal AI assistant connected to your POS, CRM, accounting platform, and project tools. Tool-augmented — generates real SQL or API queries to fetch real data, never invents numbers. Memory of prior conversations. Read-only guardrails. Built in 8–14 weeks for owners who are the data bottleneck of their own business.
If you ping your bookkeeper, your office manager, and your spreadsheet keeper to assemble an answer to a question that should take 30 seconds — and the answer takes two days, and half the time it's wrong — this is the build. Owners describe a working Custom Assistant as a "super-power." It's also the hardest service in the catalog to deliver well. Almost never the first build a client funds.
Past startup, growing or wanting to grow. You have multiple software systems with real data flowing. You also have a tribal-knowledge layer about how to interpret that data — which is exactly what makes a Custom Assistant valuable, and exactly what makes it hard.
Different systems for POS, CRM, accounting, project tools, marketing. None of them talk to each other. You don't have Snowflake or Databricks; you have software vendors with APIs.
You're making decisions slower than you'd like because the underlying data is hard to assemble. The decisions themselves you can make in seconds — getting to the data takes hours. That delta is what this build closes.
"What's the answer?" should be a 30-second question. For most established SMBs it's a multi-day, multi-person process. The cost is hidden but enormous.
The bookkeeper has the financial picture. The office manager has the operational picture. Your spreadsheet has the marketing picture. None of them have the synthesis — that's your job, and you're doing it in your head, on demand, every day.
By the time you've assembled "what was Q3 same-store revenue per location, comparing to Q3 last year?", three days have passed. The decision you needed to make based on it is now cold. Or worse, made on guesswork.
Different people use different definitions of "revenue," "margin," "active customer." The synthesis sometimes adds across incompatible definitions. You don't always notice. The decisions made on those wrong answers compound.
The architecture is the differentiator. The assistant doesn't memorize your data — it queries it. Every answer is grounded in a real query that returned real numbers, with the SQL or API call visible to you on demand.
Read-only integrations to your POS (Square, Toast, Vagaro, etc.), CRM (HubSpot, Salesforce, Pipedrive), accounting (QuickBooks, Xero), project tools (Asana, ClickUp, Jira), marketing (Google Ads, Meta, Mailchimp). Each integration is a tool the assistant can call.
You ask "what was Tuesday's revenue?" The assistant generates a real query against your POS, returns the number, shows you the query if you ask. Numbers are never hallucinated — they're never stored in the model, they're fetched on demand.
What "revenue" means at your business. What "active customer" means. What "margin" means. Captured during paid scoping, encoded into the assistant's instructions and tool definitions. Same definitions every time, no matter who's asking.
"What about last week?" returns the answer for last week, not "I don't have context." Conversation memory persists across sessions; the assistant remembers what you asked yesterday and the day before.
The assistant cannot modify data. Cannot send emails on your behalf. Cannot post to social. Cannot make purchases. Hard-enforced at the tool layer, not just instructed in the prompt. Multi-tenant isolation prevents any cross-customer data exposure.
Native Slack integration — ask the assistant in your existing workspace. Web interface for use cases that don't fit Slack. Mobile-responsive. SSO from day one.
Golden-question set with known-correct answers. Regression evals on every change. The assistant getting things wrong is the failure mode that matters most — the eval suite is what keeps it rare and debuggable.
Multi-tenant Postgres, encrypted credential storage per integration, audit logging on every tool call, role-based access, observability, cost tracking per user/per query, multi-LLM provider routing.
"Custom Assistant" is the build owners describe as a super-power once it's working. Getting it working is also the hardest engineering in the catalog. Three things we're explicit about.
Custom Assistant works best after a unifying data layer already exists — typically Operations Cockpit (#01) or one of the data services. Trying to land Custom Assistant as the first build means the assistant is querying messy disconnected systems, which compounds the difficulty.
If the question "what was Tuesday's revenue?" has six different correct answers depending on who's asking, the assistant has to know which one you mean. Definitional capture during paid scoping is a lot of the engagement value — and a lot of the work.
We don't ship Custom Assistant on day one to your whole team. Soft launch with you alone for 2 weeks, then a small team for 2–4 weeks, then broader rollout — each phase gated by eval results. This is the build where rushing the rollout hurts the most.
We map your data systems, your decision-making rhythm, and the questions you most often need answered. By end of call we know whether Custom Assistant is the right next build — or whether a different service should come first to set up the data layer.
Stakeholder interviews, definitional capture (the hard part), tool inventory across systems, golden-question set built with you, retrieval architecture sketch, fixed-quote SOW. Scoping for Custom Assistant is heavier than other services because the definitional work pays compound dividends through the build.
Weeks 1–3: tool layer (the integrations). Weeks 4–6: reasoning + tool selection logic. Weeks 7–8: memory layer, conversation persistence. Weeks 9–10: Slack / web interface, SSO, permissions. Weeks 11–12: eval suite, hardening. Weeks 13–14: soft launch with you, iterate.
2 weeks owner-only soft launch. 2–4 weeks small team. Broader rollout when eval data justifies. Quarterly business review and eval re-runs ongoing. Maintenance retainer covers hosting, monitoring, eval pipeline maintenance, integration updates, definitional updates, LLM API baseline.
No, by architecture. Numbers are never stored in the model — they're fetched on demand via tool calls that hit your real systems. Every answer can be traced back to the exact query and the raw response. If the data isn't queryable, the assistant says so rather than inventing it.
Multi-tenant isolation at the database, application, and tool-layer levels. Audit logging on every query and tool call. Role-based access — different users see different data based on their role and the data permissions you define. Multi-LLM provider routing with no training-data sharing on production traffic.
Soft launch (just you) at end of build. The first 2 weeks are iteration — you'll catch definitional gaps, integration weirdness, edge-case behavior. By week 4 of soft launch most clients describe the assistant as "super-power" useful. Broad rollout typically happens at week 6–8 of post-launch use.
Most data is. The tool layer abstracts over messiness — the assistant queries against the cleanest layer available, not raw tables. For genuinely broken data quality, we recommend Operations Cockpit (#01) or a data unification engagement first. Custom Assistant on broken data produces broken answers; we'll tell you on the discovery call.
Read-only by default. Write capabilities can be added in scoped, audited ways for specific use cases (logging a CRM note, scheduling a follow-up, posting an internal Slack message). Always opt-in, always audited. Never silent.
Hosting (pass-through), monitoring, eval pipeline maintenance, integration updates when vendors change APIs, definitional updates as your business evolves, observability, cost tracking, LLM API baseline. New integrations or new tool capabilities go through change orders.
The data unification layer that makes Custom Assistant practical. Most clients fund Cockpit first, prove the data layer is solid, then layer Custom Assistant on top.
See full details →Where Custom Assistant queries structured data, Knowledge Agent queries unstructured documents. Pairs naturally — same conversational interface, different data domain.
See full details →Bring meeting context into the same assistant. "What did we decide about pricing in the Smith meeting last Tuesday?" — answered against the same memory layer.
Discuss →A 30-minute discovery call confirms whether Custom Assistant fits your operation now, or whether a different build should come first.