Skip to content
Thaliq
Get started
Solution playbook · Internal copilot

An internal copilot that respects your permissions.

A complete implementation guide for shipping an AI agent your teams can ask about anything internal — data lake, ERP, ticketing, wiki — where the agent inherits the user's permissions instead of running as a service account.

11 min read Industry fit: mid-market · enterprise · regulated SaaS Stack: Centralized IdP + at least one MCP-capable internal system
Talk to sales Start free
The challenge

Why most internal AI tools quietly fail.

Generic chatbots can't see your stack. Custom-built copilots can — but with a service account that ignores who's asking. Either way, you end up with a tool that either knows nothing or knows too much.

Service account = everyone has admin
Most internal AI tools query systems with a single service account. The CEO and the new hire get the same data back. That's a compliance incident waiting to happen.
Cross-system context dies in the gap
Your data lake doesn't know your ERP. Your ERP doesn't know your ticket queue. Asking a question that spans systems means stitching three answers together — usually badly.
Logs that miss the 'who'
When something goes wrong, the audit trail shows the agent did it — not the human who asked. Forensics stall, compliance reports get rewritten.
Build-from-scratch is a year of detour
MCP, RAG, model routing, HITL, audit — each one is a quarter of platform work. By the time you're done, the org has moved on or your AI bet is irrelevant.
The approach

Four moves that make an internal copilot actually internal.

Thaliq wires the same four primitives — model routing, MCP gateway, HITL, observability — into a copilot that thinks like an employee with the right hat on.

01
Token passthrough on every tool call
When a user asks the copilot a question, their JWT is forwarded to each MCP server. The agent only sees data the user could see themselves. RBAC is inherited from your IdP, not duplicated.
02
MCP gateway over your stack
Wire your data lake, ERP, ticketing, wiki and observability as MCP servers (or HTTP tools with mapped auth). The copilot picks the right tool per question and chains them when needed.
03
HITL on writes, not on reads
Read-only queries flow freely. Anything that writes (create a ticket, schedule a job, send an email) suspends with a confirm card. The user sees what is about to happen and signs off.
04
Audit that names the asker
Every tool call logs the user, the agent, the tool, the result, the model, the cost. Query the audit log by user, by tool failure, by tool latency — replay any conversation in one place.
Division of labor

What Thaliq handles. What you control.

Thaliq is the agentic plumbing. The opinionated parts — what tools the copilot can use, who can talk to it, what 'sensitive' means — stay yours.

Thaliq handles
  • ✓ MCP gateway with typed tool access
  • ✓ JWT passthrough on every tool call
  • ✓ Model routing across Claude / GPT / Llama / custom
  • ✓ Resumable HITL flows for write operations
  • ✓ Per-conversation audit logs with cost per turn
  • ✓ Multi-channel delivery (Slack DM, web, mobile)
You control
  • ◆ Which MCP servers exist and what they expose
  • ◆ Your IdP, RBAC and group mappings
  • ◆ Which actions require HITL confirmation
  • ◆ Knowledge base content (Notion, Confluence, internal wikis)
  • ◆ Retention windows for conversations and tool calls
  • ◆ Compliance scope (SOC2, GDPR, ISO 27001) and DPA terms
Implementation

From IdP to first answer in four weeks.

A typical deployment for a team with one platform engineer on point. Faster if your IdP is already SAML/OIDC and you have one MCP-capable system. Slower if you need to spec a new MCP server.

  1. Week 1 01
    Discovery and tool scoping

    Inventory the top 5 questions employees ask Slack or email today. Map each question to the system that has the answer. Decide which systems get an MCP server first.

    Question inventory System map Tool priority list
  2. Week 2 02
    MCP wiring and auth

    Wire the first 2-3 MCP servers (data lake + ticketing is the usual start). Plug JWT passthrough into the auth layer of each one. Run smoke tests as different users.

    First MCP servers live JWT passthrough verified Smoke tests green
  3. Week 3 03
    HITL boundaries

    Decide which actions need HITL. Confirm-before-write is the default; some teams add a second guard for sensitive data (finance, legal). Configure the cards.

    HITL policies in Studio Sensitive-tool list Edge cases catalogued
  4. Week 4 04
    Pilot rollout per team

    Pick one team (ops or data is the usual start). Roll out via Slack DM first. Monitor for 5 days, gather feedback, tune. Open to a second team. Each team's audit log stays separate.

    Pilot team live Feedback loop Second team scheduled
Scenario walkthrough

A real internal question, end to end.

What it looks like when an ops analyst asks the copilot something that spans three systems — and the copilot answers with the analyst's permissions, not the agent's.

conversation · agent-7711
channel: web
Customer
Why did our LATAM shipments drop 8% last week?
intent: cross_system_diagnostic · channel: slack · user: ops-analyst-22
The user is recognized by their Slack identity; their JWT carries their data-lake and ERP permissions.
Agent
Checking shipment volume in the data lake for LATAM, last 14 days.
tool: query_lake(region=LATAM, range=14d) → 412 rows
The data lake MCP server runs the query as the analyst, returning only the regions they're cleared for.
Agent
Now checking open incidents on the LATAM warehouse queue.
tool: list_incidents(region=LATAM, status=open) → 3 incidents
Cross-system call. The ticketing system also receives the analyst's JWT and filters accordingly.
Agent
Volume dropped from May 12 onwards (-11.2% week over week). Three open incidents on the LATAM warehouse: a customs hold flagged on May 11 (60% of the gap), a carrier outage on May 14 (28%), and one unprocessed batch (12%). Want me to open a follow-up ticket with the supply team?
tool calls: 2 · context_chained: true
The agent threads the two queries into one coherent answer. It also offers a write action — which requires HITL.
Customer
Yes, open it and assign to the LATAM supply lead.
Agent
Confirm: create ticket in supply-board, title 'LATAM volume drop · root cause investigation', assignee: <lead-id>, link this thread.
action: confirm · onReject: stop
HITL confirmation card. The user sees exactly what's about to be written, including the assignee.
Customer
Confirmed.
Agent
Ticket created: SUPPLY-4471. Linked to this conversation. You'll get notifications on updates.
tool: create_ticket → ok · ref: SUPPLY-4471
Outcomes

What teams typically see after 90 days.

Ranges, not promises. Variability comes from how many systems you've wired, how clean your IdP groups are, and how aggressive your HITL policy is.

<2 min
Median time-to-answer
For cross-system questions that used to take 15-30 min
3-5×
Tools per chained query
Average MCP calls per answered question
100%
Audit coverage
Every tool call attributed to the asker
0
Service-account incidents
Permissions inherited via JWT passthrough

Time-to-answer measured against a pre-rollout baseline you provide. We don't quote numbers we can't replay.

Side by side

What changes vs a build-from-scratch copilot.

Comparing a typical custom-built copilot (with a service account or hardcoded auth) to a Thaliq agent in the same role.

Aspect Custom build Thaliq copilot
Time to first useful answer 3-6 months 2-4 weeks
Permission model Service account, manual ACLs JWT passthrough, IdP-native
Tool integration Custom adapters per system MCP gateway, declarative
Audit trail Logs by service account Logs by user, replayable
HITL on writes Build it yourself Built in (confirm / select / form)
Model routing Locked to one provider Claude / GPT / Llama / custom
Multi-channel Build per channel Slack / web / mobile in one config
Compliance posture Document manually GDPR-ready · DPA available · SOC 2 in progress
Readiness check

Is your stack ready for this?

An internal copilot pays back fast when you have a centralized identity story and at least one system that already exposes a clean API. If not, fix that first or talk to us about the prep work.

Do you have a centralized IdP (Okta, Auth0, Azure AD, Google) that issues JWTs?
fit

Strong fit — token passthrough plugs in directly. Group claims become RBAC for free.

Do at least 2-3 of your internal systems expose HTTP APIs or have an MCP server?
fit

Strong fit — that's enough surface for the copilot to chain queries usefully.

Is there a clear owner for 'what's sensitive' (legal, security, or a CTO call)?
fit

Strong fit — HITL policies need a decisive owner. Without one, escalation rules drift.

Are you in a regulated industry (finance, health, defense, gov)?
consider

Consider — fit, but bring legal in week 1. HIPAA / SOC2 conversations stretch timelines if started late.

Are most of your systems behind legacy auth (basic auth, shared API keys)?
consider

Consider — Thaliq supports custom headers and per-tool auth resolution, but expect a Week 0 to migrate one or two systems to bearer tokens first.

Is your IdP currently being migrated or in a half-state?
caution

Caution — token passthrough breaks if the JWT shape is in flux. Finish the IdP migration first; this playbook is twice as smooth on top of stable auth.

Ready to copilot your stack?

We'll scope a first MCP integration in one call. Bring your IdP, one system, and we'll show you token passthrough end to end.

Talk to sales Start free
Other playbooks
Customer support
HITL · escalation · multi-channel
Embedded SaaS
Multi-tenant agents inside your product