DEV Community: TorkNetwork

The 15-Point Checklist Before Deploying AI Customer-Facing

TorkNetwork — Tue, 24 Mar 2026 11:48:08 +0000

You are about to put an AI system in front of your customers. Before you do, run through these 15 checks. Each one exists because someone, somewhere, shipped without it and paid the price.

This is not theory. This is the list we use at Tork before every customer deployment.

Security & Privacy

1. PII Detection

Can your system detect personally identifiable information in real-time — in the request path, before data is stored or forwarded to a third-party API?

The minimum set: credit card numbers (Luhn validation), national ID numbers (format-specific per country), phone numbers, and email addresses. These are the data types that appear most frequently in customer conversations and carry the highest regulatory risk.

How to test: Send your chatbot a message containing a test credit card number (use 4111 1111 1111 1111 — the standard Luhn-valid test number). Check whether it appears in your conversation logs, your LLM provider's API logs, and your database. If it does, you do not have PII detection.

2. Data Isolation

If your platform serves multiple customers or business units, is data separated between tenants?

The test is specific: can Tenant A's knowledge base content, conversation history, or customer data appear in Tenant B's AI responses? This happens more often than vendors admit — shared vector databases without tenant-scoped queries are the usual cause.

How to test: Create two test tenants. Add a unique, fabricated fact to Tenant A's knowledge base (e.g., "Our company was founded on Mars in 1742"). Query Tenant B with a question that would surface this fact. If it appears, your data isolation is broken.

3. Encryption

TLS in transit. Encryption at rest. This is table stakes, not a feature.

Every connection between the user's browser and your API should be TLS 1.2 or higher. Every database, cache, and object store should encrypt data at rest. Every API key, secret, and credential should be stored in a secrets manager, not in environment variables committed to version control.

How to test: Run your API URL through an SSL checker. Review your database configuration for at-rest encryption settings. Search your repository for hardcoded API keys (grep -r "sk-" . catches more than you would expect).

4. Access Control

No open endpoints. Every API call should be authenticated. Every endpoint should be rate-limited.

Authentication means API keys at minimum, OAuth or JWT for production. Rate limiting means per-session, per-tenant, and global limits. Without rate limiting, a single user — or a bot — can exhaust your LLM API budget in minutes.

How to test: Call your chat endpoint without authentication headers. If you get a response instead of a 401, you have an open endpoint. Send 100 requests in 10 seconds from a single session. If all 100 succeed, you do not have rate limiting.

5. Data Residency

Where is the data stored? Not where your server is — where the data physically resides. This includes your database, your cache, your LLM provider's API (which may log inputs), and any analytics or monitoring tools that ingest conversation data.

POPIA requires that South African personal data be processed with appropriate safeguards. GDPR restricts data transfers outside the EU without adequate protection. CCPA gives California consumers rights over their data regardless of where the processor is located. The law that applies depends on where your customers are, not where your infrastructure is.

How to test: Map every service that touches customer data. For each one, determine the data storage region. If you cannot answer "where is this data stored?" for every service in your stack, you are not ready.

Governance & Compliance

6. Audit Trail

Can you retrieve a complete, structured record of what your AI said to a specific customer at a specific time?

A chat log is not an audit trail. An audit trail is queryable by customer, by conversation, by time range, and by action type. It includes the customer's input, what governance actions were taken (redaction, policy checks), what the AI received after processing, and what the AI responded.

How to test: Pick a conversation from last week. How long does it take you to pull the complete interaction record — including any governance actions? If the answer is "I need to check multiple systems" or "I need engineering help," your audit trail has gaps.

7. Compliance Receipts

Does each interaction generate a signed, tamper-evident record that can be presented to a regulator as evidence?

The difference between a log entry and a compliance receipt: a log entry says "the AI responded at 14:32." A compliance receipt says "at 14:32:07 UTC, the AI received input X (after PII redaction), generated response Y, which passed output policy check Z, and this record is signed with HMAC-SHA256 and has not been modified since creation."

Under GDPR, data subjects can request a full accounting of how their data was processed. Under POPIA, a regulator can request evidence of appropriate safeguards. A signed receipt answers both requests. A log line does not.

How to test: Request a compliance receipt for a specific conversation from your platform. If the response is "we have logs," that is not the same thing. If the response is a structured record with a unique ID, timestamp, and cryptographic signature — you have receipts.

8. Policy Enforcement

Can you define rules about what the AI can and cannot discuss, and are those rules enforced at the output level?

A system prompt that says "do not discuss competitors" is a suggestion. The model may follow it. It may not. Policy enforcement means scanning the AI's output before it reaches the customer and blocking or flagging responses that violate defined rules.

Topic boundaries, claim restrictions, required disclaimers, forbidden content categories — these should be code, not prompts.

How to test: Add a policy rule that blocks a specific topic. Then ask the AI about that topic in five different ways — directly, indirectly, through hypotheticals, through comparison, and through a "just curious" framing. If any of the five gets through, your policy enforcement has gaps.

9. Human Escalation

When the AI cannot resolve a query, or when the customer is frustrated, is there an automatic path to a human?

Automatic means the system detects escalation signals — explicit requests for a human ("speak to a manager"), frustration patterns (excessive capitalisation, repeated negative sentiment, insults), and repeated failed interactions (the customer asks the same question three times). Detection triggers a handoff without requiring the customer to find and click a button.

How to test: Send your chatbot "I WANT TO SPEAK TO A REAL PERSON THIS IS ABSOLUTELY UNACCEPTABLE." If the AI responds with another AI-generated message instead of routing to a human, your escalation detection is not working.

10. Kill Switch

Can you disable AI responses in under 5 seconds?

Not "start a deployment." Not "merge a PR and wait for CI." A kill switch — one action that stops the AI from responding to customers. Per-tenant (disable one client), per-topic (disable a specific capability), or global (everything stops).

When an AI starts generating harmful, incorrect, or embarrassing content at scale, the damage is measured in seconds. Your response time needs to match.

How to test: Time it. From the moment you decide to shut down, how many seconds until the AI stops responding to the next customer message? If it is more than 30 seconds, it is too slow.

Quality & Experience

11. Response Accuracy

Have you tested with real customer questions — not synthetic benchmarks, not your own team's questions, but actual messages from actual customers?

Build a test set of 50+ real customer queries (with answers verified by your team). Run them through the AI. Measure the accuracy rate. If it is below 90% for your domain, you need a better knowledge base, better prompts, or both.

How to test: Collect the last 50 customer enquiries from your support inbox. Feed them to the AI. Have your team grade each response: correct, partially correct, or incorrect. Calculate the accuracy rate. Do this before launch, not after.

12. Response Time

Sub-3 seconds for the first visible token. Customers will not wait longer.

This is not the time to generate the full response — it is the time until the customer sees the first word appearing on screen. SSE streaming makes this possible even when the full response takes 5-10 seconds to generate. Without streaming, the customer stares at a spinner and leaves.

How to test: Measure time-to-first-token under realistic conditions — not on your local machine, but on the production infrastructure, with real network latency, during peak hours. If it is consistently above 3 seconds, either your model is too slow, your infrastructure is under-provisioned, or you are not streaming.

13. Fallback Behaviour

What happens when the AI does not know the answer? There are two outcomes: it makes something up, or it says so honestly.

The correct fallback is: "I don't have that specific information. Let me connect you with our team, or you can reach us at [contact details]." The incorrect fallback is a confident fabrication — an invented policy, a wrong price, a made-up feature.

Hallucination is the default behaviour of language models. Honest fallback is a design decision that requires explicit instruction in the system prompt and validation in the output scan.

How to test: Ask the AI a question that is not in the knowledge base. Something specific and verifiable — a policy that does not exist, a product you do not sell, a location you do not operate in. If the AI invents an answer instead of acknowledging the gap, your fallback is not working.

14. Multi-Language

If your customers speak multiple languages, does the AI detect the language and respond accordingly?

Modern LLMs handle multilingual input natively — Claude, GPT-4, and Gemini all respond in the language of the input without explicit configuration. But your knowledge base may be in one language only. If a customer asks in Afrikaans and your knowledge base is in English, the RAG retrieval may fail because the embeddings do not match cross-lingually.

How to test: Send the same question in every language your customers use. Check that the response is in the correct language and that the RAG retrieval returns relevant results. Cross-lingual RAG is a known weak point — if accuracy drops in non-primary languages, you may need multilingual embeddings or translated knowledge base content.

15. Monitoring

Can you see conversations in real-time? Are you alerted when the AI escalates, when accuracy drops, or when anomalous patterns appear?

Monitoring is not "we check the dashboard on Monday morning." It is automated alerts on: escalation rate exceeding a threshold, response time degradation, repeated unanswered questions (knowledge base gaps), and governance denials (potential abuse).

How to test: Trigger an escalation. How long until someone on your team knows about it? If the answer is "when they next check the dashboard," your monitoring is reactive, not proactive.

The scorecard

Count your checks.

15/15 — You are ready. Ship it.

12-14 — You are close. The gaps are likely in monitoring, multi-language, or compliance receipts. These can be addressed post-launch if you have a plan and a timeline.

8-11 — You have significant gaps. The missing items are probably in the governance section. Deploying without them is a calculated risk — make sure the people accepting that risk understand what they are accepting.

Below 8 — You are not ready. The risk of a compliance incident, a customer data breach, or a reputational event is too high. Fix the foundations before launching.

One more thing

This checklist is designed to be platform-agnostic. You can use it to evaluate any AI chatbot, whether you built it yourself or bought it off the shelf.

If you want a head start: Tork Chat ships with items 1-10 enabled by default — PII detection, data isolation, encryption, access control, audit trails, compliance receipts, policy enforcement, escalation detection, and a kill switch. Items 11-15 depend on your specific deployment: your knowledge base quality, your infrastructure, your monitoring setup, and your customer base.

Start free at tork.network/chat. Read the full case for governed AI deployment in The Agent Crisis, available free at tork.network.

Built by the Tork team. Print the checklist. Check it before you ship. tork.network

I Compared 5 AI Chatbot Platforms on Governance — Here's What I Found

TorkNetwork — Tue, 24 Mar 2026 11:47:35 +0000

Every AI chatbot comparison you have read compares features. Integrations, pricing tiers, UI polish, template libraries. These comparisons are useful if you are choosing a chatbot for a landing page.

They are useless if you are choosing a chatbot that will interact with customers, handle personal data, and need to comply with data protection law.

I compared five AI chatbot platforms on one dimension: governance. Not features. Not pricing. Governance — the ability to detect sensitive data, prove what the AI said, enforce policies, and hand off to humans when the AI is out of its depth.

The platforms

Tidio — Popular with small businesses and e-commerce. AI chatbot powered by their Lyro product. Strong in automation and live chat.

Chatbase — Build a ChatGPT-style chatbot trained on your own data. Popular with developers and solo founders for quick deployments.

Intercom Fin — Enterprise customer support AI. Part of the Intercom platform with deep CRM integration. Used by mid-market and enterprise teams.

Freshchat — Part of the Freshworks suite. AI-powered customer messaging with Freddy AI. Common in mid-market support teams.

Tork Chat — Multi-agent AI assistant built governance-first. Full disclosure: this is our product. I will be as fair as possible, and you can verify the claims yourself at tork.network/chat.

The criteria

I tested six governance capabilities. These are not nice-to-haves — they are the baseline for any AI system that handles customer data in a regulated environment.

1. PII detection — Does the platform detect personally identifiable information (credit card numbers, national ID numbers, phone numbers, email addresses) in customer messages before processing or storing them?

2. Audit trail — Can you retrieve a complete, structured record of what the AI said to a specific customer at a specific time? Not a chat log — a queryable audit record.

3. Compliance receipts — Does each interaction generate a signed, tamper-evident receipt that can be presented to a regulator as proof of what occurred?

4. Escalation controls — Can you define rules for when the AI should stop responding and hand off to a human? Not just a "talk to agent" button — automatic detection of frustration, confusion, or out-of-scope queries.

5. Data isolation — If the platform serves multiple customers, is your data isolated from other tenants? Can one tenant's data leak into another tenant's AI responses?

6. Policy enforcement — Can you define rules about what the AI can and cannot say? Topic restrictions, claim limitations, required disclaimers. Enforced at the output level, not just suggested in the system prompt.

Platform-by-platform results

Tidio

Tidio is a strong platform for small teams that need live chat with AI augmentation. Lyro, their AI agent, can be trained on your website content and FAQ documents, and it handles straightforward customer queries well.

On governance, Tidio is limited. There is no PII detection — customer messages are processed and stored as-is. If a customer types their credit card number, it sits in the conversation log. Chat history is available through the dashboard, which serves as a basic log, but there are no structured audit records and no compliance receipts. Escalation is manual — the customer or the operator triggers a handoff. There is no automatic detection of frustration or out-of-scope queries. Tidio does offer workspace separation for teams, but there is no tenant-level data isolation in the way a multi-tenant SaaS requires. Policy enforcement is limited to what you put in the AI's training data and instructions.

Best for: Small businesses that need a quick, affordable chatbot. Not suitable if you have compliance obligations for customer data.

Chatbase

Chatbase makes it remarkably easy to deploy a custom chatbot. Upload your documents, connect your website, and you have a working bot in minutes. For developers and solo founders who need a fast deployment, it is hard to beat.

Governance is minimal. There is no PII scanning — data flows through to the model as submitted. Conversation history is available and exportable, which is better than some alternatives, but there are no signed audit records. Escalation support is basic — you can configure keyword-based triggers to redirect to a human or a URL, but there is no sentiment analysis or frustration detection. Data is associated with your chatbot, but Chatbase does not offer the kind of cryptographic data isolation that regulated industries require. Policy enforcement relies on the system prompt — effective for broad instructions, but not enforceable at the output layer.

Best for: Developers who need a quick, functional chatbot trained on custom data. Not suitable for customer-facing deployments with compliance requirements.

Intercom Fin

Intercom Fin is the most mature platform in this comparison from a product perspective. It sits inside the Intercom ecosystem, which means deep integration with ticketing, CRM, and analytics. Fin is trained on your help centre content and resolves a significant percentage of support queries without human intervention.

On governance, Fin is ahead of the other third-party platforms here. Intercom provides content filtering capabilities and the ability to restrict topics. Audit logs are available through the platform — conversation records are detailed and queryable. However, these are standard application logs, not cryptographic compliance receipts. Escalation is well-implemented — you can define routing rules based on conversation attributes, customer segments, and topic detection. Fin can recognise when it cannot resolve a query and hand off to a human agent with context. Data isolation is handled through Intercom's workspace architecture, which is robust for most use cases.

The trade-off is cost and complexity. Fin is priced as an enterprise product and requires the broader Intercom platform. If you are already an Intercom customer, Fin is a strong choice. If you are evaluating standalone governance, the platform cost is significant.

Best for: Mid-market and enterprise teams already on Intercom who need AI support with good escalation. Governance is partial — better than most, but not purpose-built for compliance.

Freshchat

Freshchat, part of the Freshworks suite, offers AI-powered customer messaging through Freddy AI. It occupies a solid middle ground — more capable than the lightweight tools, more accessible than enterprise platforms.

Freddy includes basic sentiment detection, which gives it some awareness of customer frustration. Standard conversation logging is available through the Freshworks platform. There are no compliance receipts — interactions are logged but not signed or independently verifiable. Escalation uses routing rules that can be configured based on keywords, topics, and basic sentiment signals. Data separation follows the Freshworks tenant model, which is adequate for most business use cases. Policy enforcement is limited to conversation design and bot configuration — there is no runtime output scanning.

Best for: Mid-market support teams already in the Freshworks ecosystem. Governance is basic but functional for low-regulation environments.

Tork Chat

Tork Chat was built governance-first. The governance layer is not an add-on — it is a node in the multi-agent state machine. Every message passes through it.

PII detection runs in real-time on every input and every output. Credit card numbers (Luhn-validated), South African ID numbers (13-digit format), phone numbers, and email addresses are detected and redacted before the message reaches the LLM. The model never sees raw PII.

Every governance scan generates an HMAC-signed audit receipt with a unique ID. Receipts record what was scanned, what was detected, what action was taken, and when. They are stored independently of the conversation and are queryable by conversation, tenant, or time range. These are not log entries — they are structured compliance records designed to be presented to a regulator.

Escalation detection is automatic. Regex pattern matching catches explicit handoff requests ("speak to a manager"). A frustration classifier detects excessive capitalisation and negative sentiment patterns. When escalation triggers, the AI stops generating — a fixed handoff message is returned without an LLM in the loop.

Data isolation is enforced at the tenant level. Each tenant has their own knowledge base (RAG scoped by tenant ID), session store, and bot configuration. Cross-tenant data leakage is architecturally prevented, not just policy-prevented.

Policy enforcement operates at the output layer. The governance scan checks every AI response before it reaches the customer. Topic restrictions and claim limitations are enforced at runtime, not suggested in the system prompt.

Best for: Customer-facing AI deployments where compliance, audit trails, and data protection are requirements — not features. Available to try free at tork.network/chat.

The comparison table

Capability	Tidio	Chatbase	Intercom Fin	Freshchat	Tork Chat
PII detection	No	No	Partial	No	Yes
Audit trail	Basic logs	Chat history	Detailed logs	Standard logs	HMAC-signed receipts
Compliance receipts	No	No	No	No	Yes
Escalation controls	Manual only	Keyword-based	Rule-based	Keyword + sentiment	Auto-detect + pattern
Data isolation	Workspace	Per-chatbot	Workspace	Tenant model	Tenant-scoped RAG
Policy enforcement	Training data	System prompt	Content filtering	Bot config	Runtime output scan

To read this table: "Partial" means the capability exists in some form but does not meet the standard you would need for a compliance audit. "Basic logs" means conversation records exist but are not structured, signed, or independently queryable as audit evidence.

What this means for you

The right choice depends on your context.

If your chatbot is internal-only — answering employee questions, summarising documents, routing internal tickets — governance matters less. The risk profile is lower. Any of these platforms will work, and you should choose based on features, integrations, and price.

If your chatbot talks to customers — answering enquiries, handling personal data, making statements that could be interpreted as commitments — governance is not optional. You need PII detection before a customer's ID number ends up in a log file. You need audit receipts before a regulator asks what your AI said. You need escalation rules before a frustrated customer gets three more paragraphs of AI-generated apology instead of a human.

The question is not whether you need governance. If customers interact with your AI, you do. The question is whether you build it in now — when it is a design decision — or bolt it on later, when it is a remediation project triggered by an incident.

Every platform in this comparison does something well. Tidio is fast and affordable. Chatbase is the quickest path from documents to chatbot. Intercom Fin has the deepest enterprise integration. Freshchat is a solid all-rounder in the Freshworks ecosystem. None of them were built with governance as the primary design constraint.

Tork Chat was. That is not a criticism of the other platforms — it is a statement about what we chose to prioritise. If governance is your priority too, evaluate it yourself.

Evaluate Tork Chat free at tork.network/chat. Read more about the case for governed AI agents in The Agent Crisis, available free at tork.network.

How We Deployed AI Customer Service for a Vehicle Rental Company in 2 Weeks

TorkNetwork — Tue, 24 Mar 2026 11:47:02 +0000

This is a case study from a real deployment of Tork Chat for a vehicle rental company in South Africa. The numbers are honest estimates based on observed usage, not vanity metrics.

The client

A mid-size vehicle rental operator based in Cape Town with 200+ vehicles across three locations. Their fleet ranges from economy hatchbacks to luxury SUVs, with a growing 4x4 and bakkie segment for tourists and contractors. They serve a mix of walk-in airport customers, online bookings, corporate accounts, and long-term leases.

On a typical day, they handle 50+ customer enquiries — split roughly between WhatsApp, phone calls, email, and their website contact form. The enquiry mix is predictable: pricing and availability questions account for about 40%, booking and reservation requests about 25%, insurance and policy questions about 20%, and the remaining 15% is a mix of complaints, after-hours messages, and general questions.

The problem

The company had three staff members handling customer enquiries. Their day looked like this:

The same ten questions, asked fifty times. "How much for an SUV for the weekend?" "Do you deliver to the airport?" "What's your fuel policy?" "Can I take the car across the border into Namibia?" "Is insurance included?" These questions have definitive answers that do not change from day to day. But each one required a human to read the message, find the answer, type a response, and move on to the next.

After-hours enquiries went unanswered until the next morning. The rental industry does not sleep at 5pm. Tourists landing at 9pm, business travellers adjusting plans at midnight, conference organisers confirming fleet bookings on a Sunday — these enquiries sat in inboxes until Monday morning. By then, some customers had already booked with a competitor.

There was no structured lead capture. Customer details — names, email addresses, phone numbers, travel dates — were scattered across WhatsApp threads, email chains, and handwritten notes. Following up on an enquiry from two days ago meant searching through message history.

There was zero compliance infrastructure. Customer ID numbers, credit card details, and personal information flowed through unmonitored channels. South Africa's Protection of Personal Information Act (POPIA) requires that personal data be processed lawfully, with appropriate safeguards. The company was technically exposed on every enquiry that included personal data.

And there was no visibility into what customers were actually asking. The business had no data on enquiry volume, peak hours, common questions, or conversion rates from enquiry to booking. Decisions about staffing, pricing, and fleet composition were based on gut feel.

What we built

We deployed seven specialist AI agents as a chat widget on the company's website, powered by Tork Chat.

Engagement agent. Handles greetings, small talk, and opening conversation. When a visitor says "Hi" or "Good morning," the engagement agent responds warmly and asks how it can help. No RAG retrieval needed — this agent sets the conversational tone and routes deeper questions to specialists.

Fleet agent. Answers vehicle availability and specification queries. "What SUVs do you have?" triggers a RAG search against the company's vehicle catalogue. The agent retrieves relevant fleet information — vehicle types, features, capacity — and presents it conversationally. The knowledge base is updated whenever the fleet changes.

Policy agent. Handles insurance, waivers, deposits, fuel policy, cross-border rules, and terms and conditions. This agent rewrites the customer's query to bias toward policy-relevant documents before searching the knowledge base. When a customer asks "Can I drive to Namibia?", the agent retrieves the cross-border policy and explains the requirements, additional costs, and required documentation.

Quote agent. Provides pricing information by searching rate-related documents in the knowledge base. The agent retrieves current pricing and presents it in context. It does not calculate dynamic quotes — it surfaces published rates and directs the customer to complete a booking for a final price.

Booking agent. Captures booking intent and extracts details. When a customer says "I want to book an SUV from the 15th to the 20th at the airport," the agent extracts the dates, location, and vehicle preference, confirms the details, and directs the customer to complete the reservation through the website or by calling the branch. The agent does not process bookings — it captures the structured intent and ensures the handoff is smooth.

Needs assessment agent. Handles vague or incomplete queries. When a customer says "I need a car," the agent identifies what information is missing — travel dates, pickup location, vehicle preference — and asks one clarifying question at a time. It does not dump a form. It has a conversation, progressively gathering the details needed to route to the right specialist.

Escalation agent. Detects frustration, explicit requests for a human, and conversations where the AI is not resolving the issue. This agent does not generate an AI response. It produces a fixed handoff message — "I'll connect you with our team" — and flags the conversation for human follow-up. The detection uses both regex pattern matching (phrases like "speak to a manager," "this is unacceptable") and a frustration classifier that catches excessive capitalisation and repeated negative sentiment.

All seven agents are orchestrated by a LangGraph state machine that classifies intent on every message and routes to the appropriate specialist. The routing is dynamic — a customer can ask about fleet in one message, switch to pricing in the next, and then ask about insurance, and each message is handled by the right agent.

The governance layer

Every message through the system — inbound and outbound — is scanned by Tork's governance pipeline before it reaches the LLM.

PII detection runs in real-time. South African ID numbers (13-digit format), credit card numbers (Luhn-validated), phone numbers, and email addresses are detected and redacted before the message is processed. The LLM never sees raw PII. The redacted version is what gets stored, what gets sent to the model, and what appears in logs.

Audit receipts are generated for every interaction. Each governance scan — input and output — produces a receipt with a unique ID, recording what was scanned, what was detected, and what action was taken. These receipts are stored independently of the conversation and can be retrieved by conversation ID, tenant, or time range.

POPIA alignment was built in from day one. The client did not need to configure compliance settings, hire a data protection officer for the chatbot, or audit the system after launch. Personal data handling was a design constraint, not an afterthought. When their legal team asked "how does the chatbot handle personal information?", the answer was a one-page technical summary with receipt examples — not a conversation about what needed to be built.

If governance denies a message — because of a policy violation or detected risk — the system short-circuits. No LLM call, no response generation. The denial is recorded with a receipt, and the customer receives a safe fallback. The system does less work, not more.

Results

These are estimates based on observed usage during the first month of deployment. We qualify them as estimates because the company did not have baseline metrics for pre-deployment comparison in all categories.

Estimated 70%+ of routine enquiries handled without human intervention. Pricing, availability, policy, and general questions are answered by the AI. The remaining 30% includes complex booking modifications, complaints that require human judgement, and edge cases outside the knowledge base. This is consistent with industry benchmarks for domain-specific AI assistants with curated knowledge bases.

Sub-2-second average response time. From message received to first token streamed back to the customer. SSE streaming means the customer sees the response appearing token by token rather than waiting for a complete response. Perceived latency is significantly lower than actual generation time.

Automated lead capture. Names, email addresses, phone numbers, and travel dates mentioned in conversations are extracted and structured. Before deployment, this information was scattered across channels. Now it feeds directly into the company's follow-up workflow.

24/7 availability. The most immediate impact. Enquiries that previously waited until the next business day now receive an instant response at any hour. For a tourism-facing business where customers book from different time zones, this is a direct revenue impact — though we do not have the data to quantify it precisely.

Staff redeployed to higher-value work. The three staff members who were previously spending their day answering the same ten questions are now focused on closing bookings, managing VIP accounts, and handling the complex enquiries that the AI escalates. This is not a headcount reduction — it is a reallocation.

Enquiry visibility for the first time. The company now has data on what customers ask, when they ask it, which questions lead to bookings, and where the AI struggles. This has informed decisions about fleet composition, pricing, website content, and staffing schedules. Prior to deployment, these were guesswork.

The technical stack

Python 3.12 + FastAPI for the API layer. Async throughout — every external call (LLM, governance, database, cache) is non-blocking.

LangGraph for multi-agent orchestration. The state machine handles intent classification, agent routing, and response generation as a compiled graph. Adding a new agent means adding a node and an edge.

Anthropic Claude for language generation. Claude Haiku for intent classification (speed) and response generation for routine queries. Claude Sonnet available for complex queries requiring deeper reasoning.

Supabase with pgvector for the knowledge base. Vehicle catalogue, pricing, policies, and FAQs are chunked, embedded, and stored as vectors. RAG retrieval uses cosine similarity with a tuned threshold.

Upstash Redis for session management. Conversation history is cached with a 24-hour TTL and a rolling window of recent messages for context.

SSE streaming for real-time response delivery. The widget renders tokens as they arrive rather than waiting for the full response.

Multi-tenant architecture. The same engine serves multiple clients. Each tenant has their own knowledge base, bot configuration, system prompt, and widget styling. Onboarding a new client means configuring a tenant — not deploying new infrastructure.

What we would do differently

Start with three agents, not seven. For an MVP, you need engagement (greetings), a general RAG agent (handles everything with one knowledge base), and escalation (hand-off to humans). The specialist routing — fleet, policy, quote, booking, needs — is a refinement that improves accuracy but is not necessary for a first deployment. We built all seven because we had the architecture ready, but if we were advising a team starting from scratch, we would say: ship three, measure, then specialise.

Invest more in escalation detection from day one. We underestimated how important this would be. The escalation agent is the simplest agent in the system — it returns a fixed message and flags for human follow-up. But detecting when to escalate is the hardest classification problem. Customers express frustration in subtle ways that regex and even LLM classifiers miss. We added the all-caps detector and expanded the pattern list after launch, based on conversations where the AI tried to resolve something a human should have handled. If starting over, escalation detection would be the first thing we tested with real customer data.

Test with real customer data sooner. We built the knowledge base from the company's website content, policy documents, and pricing sheets. This covered 80% of what customers ask. The other 20% — questions phrased in ways we did not anticipate, local slang, questions that span multiple categories — only surfaced once real customers started using the system. We refined the knowledge base weekly during the first month. A one-week pilot with live traffic before "launch" would have caught most of these gaps earlier.

Build the analytics dashboard earlier. We added enquiry analytics — question categories, peak hours, escalation rates, unanswered question patterns — after the initial deployment. It should have been in the first release. The client's most common feedback in week one was "this is great, but what are customers actually asking?" The data was in the database. The dashboard to surface it was not.

Is this relevant to your business?

This deployment was for vehicle rental, but the pattern applies to any service business that handles a predictable set of customer enquiries: property management, insurance brokers, medical practices, legal intake, hospitality, logistics.

If your team spends hours each day answering the same questions, if after-hours enquiries go unanswered, if customer data flows through unmonitored channels, and if you have no visibility into what your customers are actually asking — this is solvable.

The technology exists. The governance layer exists. The deployment timeline is weeks, not months.

See it in action at tork.network/chat, or read about the broader thesis behind governed AI agents in The Agent Crisis, available free at tork.network.

Built by the Tork team. Multi-agent AI with governance for customer-facing deployments. tork.network

AI Governance Is a Seatbelt, Not Invincibility — And That's the Point

TorkNetwork — Tue, 24 Mar 2026 11:46:29 +0000

I am going to say something that most governance vendors will not: our product will not prevent every bad thing your AI does.

It will catch most of them. It will log all of them. And when something slips through — because something will — you will have cryptographic proof of what happened, when, and what your system did about it.

That is not a failure of governance. That is the entire point.

The invincibility myth

Open any AI governance vendor's website. Count the absolutes. "Complete compliance." "Total protection." "Zero risk deployment." "Bulletproof AI safety."

These are lies. Polite, well-designed, investor-friendly lies — but lies.

No PII detection system catches every pattern. South African ID numbers follow a predictable format. Credit card numbers pass the Luhn check. These are detectable. But a customer who writes "my number is nine five zero two zero one five eight zero zero zero eight six" has just bypassed every regex and most ML classifiers. A customer who puts their ID number in an image, or splits it across two messages, or embeds it in a question about someone else — these are edge cases that no scanner handles perfectly.

No policy enforcement system prevents every hallucination. LLMs are stochastic. They generate plausible text, not verified facts. You can constrain outputs, scan responses, and block known failure patterns — but you cannot guarantee that a model with 175 billion parameters will never produce a sentence you did not anticipate.

Anyone who tells you otherwise is selling a feeling, not a product.

The seatbelt

A seatbelt does not prevent car crashes. It does not make you a better driver. It does not stop the other driver from running a red light.

What it does: when the crash happens, it dramatically reduces the damage. It keeps you in the seat instead of through the windshield. It converts a fatal outcome into a survivable one.

AI governance is a seatbelt.

It will not prevent every PII leak. It will detect the vast majority of them — in real time, in the request path, before the data reaches the LLM or the database. The ones it misses are logged with enough context to detect them in review.

It will not prevent every hallucination. It will scan every response against policy rules and flag violations before the customer sees them. The hallucinations it misses are recorded with audit receipts, so when a customer says "your chatbot told me X," you can verify exactly what it said.

It will not prevent every rogue agent action. It will enforce escalation rules, maintain human override capability, and provide a kill switch that works in seconds, not deployments.

The seatbelt framing is uncomfortable for sales teams because it admits imperfection. It is comfortable for engineers and compliance officers because it is honest. And in my experience, honest framing builds longer customer relationships than invincibility promises.

What "defensible" actually means

When something goes wrong with your AI — and it will — you end up in one of two positions.

Position A: "We had no idea." No logs. No audit trail. No evidence of what the AI said. No record of governance scans. The regulator, the customer, or the lawyer asks what happened, and you reconstruct it from server logs and Slack threads. Your legal counsel describes this as "indefensible."

Position B: "We caught it in 200 milliseconds." You have a cryptographic receipt showing exactly what the customer sent, what governance detected, what the AI received (after redaction), what the AI responded, what the output scan flagged, and what action was taken. The receipt has a unique ID, a timestamp, and is stored independently of the conversation. Your legal counsel describes this as "defensible."

The difference between these two positions is not whether the incident happened. Incidents happen. The difference is whether you can prove you had systems in place, those systems were running, and you responded appropriately.

This is what governance actually provides: not prevention, but proof.

In 2023, the Italian data protection authority temporarily banned ChatGPT — not because it made errors, but because OpenAI could not adequately demonstrate how user data was being processed. The issue was not the AI's behaviour. It was the inability to prove what the AI was doing with the data. Governance that generates verifiable receipts addresses this directly.

When Air Canada's chatbot fabricated a bereavement discount, the company had no audit trail showing what the chatbot was instructed to say versus what it actually said. A governance layer with output scanning would not have prevented the hallucination with certainty. But it would have flagged a response that referenced a policy not present in the knowledge base, and it would have produced a receipt proving the system attempted to catch it.

Defensible does not mean perfect. It means prepared.

Three layers of realistic governance

Layer 1: Detection

Catch PII. Catch policy violations. Catch anomalies.

Real-time scanning of every input and every output. Regular expressions for structured data (credit cards, ID numbers, phone numbers). ML classifiers for unstructured PII (names mentioned in context, addresses described in prose). Policy rules for topic boundaries, claim restrictions, and escalation triggers.

Will you catch 100%? No. Aim for 99%+. The last 1% is why you have Layer 2.

Detection is not just about blocking bad content. It is about knowing what passed through your system. A scan that returns "allow" is just as important as a scan that returns "deny" — both generate receipts, both are auditable, both prove the system was running.

Layer 2: Evidence

Cryptographic receipts for every interaction.

Every scan — input and output — produces a receipt with a unique ID. The receipt records what was scanned, what was detected, what action was taken, and when. Receipts are stored independently of conversation logs. They cannot be retroactively modified without detection.

When something goes wrong, you do not grep through log files hoping to find the relevant entry. You query receipts by conversation ID, by tenant, by time range, or by action type. The data is structured, indexed, and verifiable.

This layer exists for the incidents that Layer 1 misses. Detection failed, but evidence did not. You can prove the system was running, prove what it scanned, and prove the outcome. The gap between "our system should have caught this" and "our system did not catch this, but here is the complete record of what happened" is the gap between a compliance violation and a documented incident.

Layer 3: Response

When the AI fails, humans take over immediately.

Escalation rules that trigger on frustration signals, explicit handoff requests, and repeated failed interactions. A kill switch that disables AI responses in seconds — per tenant, per topic, or globally. Human override capability that lets a supervisor intervene in a live conversation.

Response is the layer most governance vendors ignore because it requires operational design, not just software. A kill switch is useless if nobody is monitoring. Escalation rules are useless if there is no human to escalate to. This layer is as much about process as it is about code.

The three layers work together. Detection catches most problems before they reach the customer. Evidence ensures every interaction is recorded regardless of what detection caught. Response ensures that when both detection and evidence reveal a problem, a human can act on it immediately.

No single layer is sufficient. All three together give you a defensible position.

Why this framing sells better

I know this reads like an argument against selling governance. It is the opposite.

Customers who have been burned by vendor promises are the most skeptical buyers in enterprise software. They have heard "100% uptime," "zero data loss," and "complete protection" before. They know what those claims are worth when the incident report lands on their desk.

"We will reduce your risk by 95%+ and give you a complete audit trail for the rest" is a statement that a CTO can repeat to their board without feeling like they are being dishonest. "We eliminate all AI risk" is a statement that makes a CTO wonder what you are hiding.

The seatbelt framing also manages expectations after the sale. Customers who understand that governance is risk reduction — not risk elimination — have fewer complaints when an edge case gets through. They expected it. They planned for it. The audit receipt is there. The escalation path worked. The system performed as described.

Customers who were sold invincibility experience every edge case as a broken promise. They call support angry. They question the product. They churn.

Honest framing produces longer contracts. In a market full of absolute claims, "we are really good at this but not perfect, and here is how we handle the imperfection" is a differentiator.

How we built this into Tork

At Tork, every design decision starts from the assumption that the system will encounter inputs it cannot perfectly handle.

Every marketing claim is probabilistic, not absolute. We detect PII. We do not claim to detect all PII. We scan outputs. We do not claim to prevent all hallucinations. We generate audit receipts. We do claim those receipts are cryptographic and tamper-evident — because that is a property of the system, not a probabilistic outcome.

Every governance receipt in Tork Chat is a structured record with a unique ID, stored independently of the conversation. When our customers face a compliance query, they pull receipts — not log files.

Every escalation path ends at a human. The escalation agent in our multi-agent system does not generate an AI response. It produces a fixed handoff message and routes to a person. No LLM in the loop when a customer is frustrated. This is not a limitation of our AI. It is a design choice that acknowledges the AI's limitations.

Every tenant has a kill switch. One API call disables AI responses for that tenant. The widget falls back to a contact form. This exists not because we expect to use it often, but because the alternative — a deployment pipeline — takes minutes when you need seconds.

We built governance as a seatbelt because that is what our customers actually need: a system that reduces risk, proves what happened, and lets humans take over when the AI is not enough.

The uncomfortable truth

If your governance vendor promises 100% protection, one of two things is true:

They do not understand the problem space. PII detection, hallucination prevention, and policy enforcement are probabilistic problems operating on stochastic systems. Anyone who has built these systems knows that edge cases are infinite and perfection is asymptotic.

Or they understand it perfectly and chose to lie anyway, because "95%+ detection with complete audit trails" does not look as good on a slide deck as "total protection."

Either way, you should ask harder questions. Ask for false negative rates. Ask what happens when detection fails. Ask to see an audit receipt from a real incident. Ask how fast the kill switch works. Ask who gets paged at 3am when the AI starts misbehaving.

The vendors who answer these questions clearly are the ones who have thought about failure. The ones who deflect back to "complete protection" have not.

Governance is risk reduction, not risk elimination. The companies that understand this will build more resilient systems, maintain longer customer relationships, and have better outcomes when — not if — something goes wrong.

Build your seatbelt. Skip the invincibility cape.

We built Tork on this philosophy. Governance-first AI for customer-facing deployments. The honest kind. Read more about governed AI agents in The Agent Crisis, available free at tork.network.

Building a Multi-Agent Customer Service System with LangGraph — A Practical Guide

TorkNetwork — Tue, 24 Mar 2026 11:45:55 +0000

This is not a toy example. We are going to build a multi-agent customer service system where different AI agents handle different types of enquiries — greetings, product queries, pricing, bookings, policy questions, and escalation to humans. By the end, you will have a working LangGraph state machine that classifies intent, routes to the right agent, retrieves relevant context via RAG, and generates a response.

The code here is drawn from Tork Chat, a production multi-agent assistant deployed in the vehicle rental industry. I have simplified some of the production concerns (governance, multi-tenancy, observability) to focus on the multi-agent pattern itself.

Why multi-agent over single-prompt

A single prompt can answer a single question well. It falls apart when a customer does this:

"What SUVs do you have?" → fleet query
"How much for 3 days?" → pricing
"OK book it for next Friday" → booking intent
"What's your fuel policy?" → policy lookup
"Actually this is too expensive, let me speak to someone" → escalation

A single system prompt that tries to handle fleet knowledge, pricing logic, booking flows, policy details, and escalation detection simultaneously is a prompt that does none of them well. It gets long, contradictory, and fragile. Change one instruction and something else breaks.

The multi-agent approach separates concerns. Each agent has a focused system prompt and searches a focused part of the knowledge base. The routing layer decides which agent handles each message. The agents do not need to know about each other.

Setting up LangGraph

pip install langgraph anthropic

LangGraph gives you three primitives:

StateGraph: A directed graph where state flows from node to node
Nodes: Async functions that receive state and return updates
Edges: Connections between nodes — either fixed or conditional

The mental model: state enters the graph, flows through nodes that transform it, and exits with a result. Each node reads what it needs from state and returns only the fields it wants to update.

Defining the state

The state is a TypedDict that carries everything the graph needs. Every node reads from it and writes to it.

from typing import TypedDict, Optional, Literal

class ChatState(TypedDict):
    # Input — set once at the start
    message: str
    tenant_id: str
    session_id: str

    # Tenant context — set by resolve_tenant
    tenant: Optional[dict]
    bot_config: Optional[dict]

    # Routing — set by classify_intent
    intent: Optional[Literal[
        "greeting", "fleet_query", "pricing", "booking",
        "policy", "complaint", "general", "escalate",
    ]]
    current_agent: Optional[str]

    # RAG context — set by specialist agents
    chunks: list
    sources: list

    # Response — set by generate_response
    response: Optional[str]
    escalated: bool

    # Conversation history
    history: list

Each field has a clear owner — the node that sets it. This matters because LangGraph merges node return values into the state. If two nodes both return chunks, the last one wins. By designing the state so each field has one writer, you avoid subtle bugs.

The intent field uses a Literal type. This is documentation, not enforcement — Python will not reject an invalid intent at runtime. But it makes the valid values explicit for anyone reading the code.

Intent classification

The classifier is the routing brain. It takes the user's message and returns one intent label. We use Claude Haiku because this is a low-stakes, high-frequency call — it needs to be fast, not deep.

async def classify_intent_node(state: dict) -> dict:
    message = state["message"]

    # Pre-check: skip the LLM for obvious escalations
    if matches_escalation_patterns(message):
        return {"intent": "escalate"}

    response = await client.messages.create(
        model="claude-haiku-4-5-20251001",
        max_tokens=10,
        temperature=0,
        system=(
            "Classify the user message into exactly one intent: "
            "greeting, fleet_query, pricing, booking, policy, complaint, "
            "general, escalate. Respond with ONLY the intent word, nothing else.\n\n"
            "Use 'escalate' when the user wants to speak to a human, manager, "
            "or supervisor, or expresses strong frustration or anger."
        ),
        messages=[{"role": "user", "content": message}],
    )

    intent = response.content[0].text.strip().lower().replace(".", "")

    valid_intents = {
        "greeting", "fleet_query", "pricing", "booking",
        "policy", "complaint", "general", "escalate",
    }
    if intent not in valid_intents:
        intent = "general"

    return {"intent": intent}

Three design decisions here:

temperature=0 — We want deterministic classification. The same message should always route to the same agent. Temperature zero does not guarantee this (Claude is not fully deterministic), but it gets close enough.

max_tokens=10 — The response should be a single word. Setting a low token limit prevents the model from writing an explanation. If it tries to say "I think this is a fleet_query because..." it gets cut off after the intent word.

The pre-check pattern — Before calling the LLM, we check for obvious escalation signals with regex. This catches "speak to a manager," "this is unacceptable," and all-caps messages without burning an API call.

import re

ESCALATION_PATTERNS = [
    r"\bspeak to (a )?(human|person|agent|manager|supervisor)\b",
    r"\bmanager\b",
    r"\bhuman agent\b",
    r"\bescalate\b",
    r"\bcomplaint\b",
    r"\bunacceptable\b",
]

def matches_escalation_patterns(message: str) -> bool:
    for pattern in ESCALATION_PATTERNS:
        if re.search(pattern, message, re.IGNORECASE):
            return True

    # Frustration indicator: excessive caps
    alpha_chars = [c for c in message if c.isalpha()]
    if len(alpha_chars) >= 10:
        upper_ratio = sum(1 for c in alpha_chars if c.isupper()) / len(alpha_chars)
        if upper_ratio > 0.5:
            return True

    return False

The all-caps check is important. Customers who type "THIS IS RIDICULOUS I HAVE BEEN WAITING FOR AN HOUR" are not asking a question. They want a human. The LLM might classify this as "complaint" and try to generate a soothing response. The regex pre-check catches it and routes directly to escalation.

Specialist agent nodes

Each agent is an async function that receives the graph state and returns updates. The pattern is consistent: read the message, query the relevant knowledge, and return chunks for the response generator.

Fleet search — queries the full knowledge base for product information:

async def fleet_search_node(state: dict) -> dict:
    tenant = state.get("tenant")
    if not tenant:
        return {"chunks": [], "current_agent": "fleet"}

    query = state.get("query_content") or state["message"]
    chunks = await rag_engine.retrieve(query, tenant["id"], top_k=5)

    return {
        "chunks": chunks,
        "sources": [{"content": c.content[:200], "similarity": c.similarity} for c in chunks],
        "current_agent": "fleet",
    }

Policy search — rewrites the query to bias toward policy-related chunks:

async def policy_search_node(state: dict) -> dict:
    tenant = state.get("tenant")
    if not tenant:
        return {"chunks": [], "current_agent": "policy"}

    query = state.get("query_content") or state["message"]
    policy_query = f"policy terms conditions: {query}"
    chunks = await rag_engine.retrieve(policy_query, tenant["id"], top_k=5)

    return {
        "chunks": chunks,
        "sources": [{"content": c.content[:200], "similarity": c.similarity} for c in chunks],
        "current_agent": "policy",
    }

Engagement — handles greetings. No RAG needed:

async def engagement_node(state: dict) -> dict:
    return {
        "chunks": [],
        "current_agent": "engagement",
    }

Needs assessment — the interesting one. When the user's query is too vague to route to a specialist, this agent checks what information is missing and asks a clarifying question:

from app.models.schemas import ChunkResult

def assess_missing_info(message: str, history: list) -> list[str]:
    all_text = " ".join(m.get("content", "") for m in history)
    all_text = (all_text + " " + message).lower()

    missing = []
    if not re.search(r'\d{1,2}[/-]\d{1,2}', all_text):
        missing.append("travel dates (pickup and return)")
    if not any(loc in all_text for loc in ["cape town", "johannesburg", "airport"]):
        missing.append("preferred pickup location")
    if not any(v in all_text for v in ["sedan", "suv", "bakkie", "van"]):
        missing.append("type of vehicle")

    return missing


async def needs_node(state: dict) -> dict:
    message = state.get("query_content") or state["message"]
    history = state.get("history", [])
    missing = assess_missing_info(message, history)

    if missing:
        focus = missing[0]
        context = (
            f"The customer's query is missing some details. "
            f"Still needed: {', '.join(missing)}. "
            f"Politely ask about: {focus}. "
            "Keep it conversational — don't list all missing items at once."
        )
    else:
        context = "The customer has provided enough context. Answer helpfully."

    context_chunk = ChunkResult(
        content=context,
        metadata={"type": "needs_assessment"},
        similarity=1.0,
    )

    return {"chunks": [context_chunk], "current_agent": "needs", "sources": []}

The needs agent does not call RAG. It manufactures a synthetic chunk that instructs the response generator on what to ask. This is a useful pattern: you can steer the final LLM response by injecting context as if it came from RAG.

Escalation — the agent that does not generate an AI response:

async def escalation_node(state: dict) -> dict:
    return {
        "escalated": True,
        "response": "I'll connect you with our team. A human agent will reach out shortly.",
        "current_agent": "escalation",
    }

The escalation agent returns a fixed response and skips the LLM entirely. This is deliberate. When a customer is frustrated enough to ask for a human, the worst thing you can do is run their message through another round of AI. The escalation node sets response directly and gets routed past generate_response to save_message.

The routing edge

The routing function maps intents to agent node names:

def route_by_intent(state: dict) -> str:
    intent = state.get("intent", "general")

    routing = {
        "escalate": "escalation",
        "greeting": "engagement",
        "fleet_query": "fleet_search",
        "booking": "booking",
        "policy": "policy_search",
        "complaint": "policy_search",
        "pricing": "quote",
        "general": "needs",
    }

    return routing.get(intent, "engagement")

Two decisions to note:

Complaints route to policy search. A complaint like "your insurance policy is unfair" is best addressed by surfacing the actual policy. The policy agent retrieves the relevant terms, and the response generator can explain them. Routing complaints to a generic agent produces vague apologies.

Unknown intents default to engagement. If the classifier returns something unexpected, we fall back to the friendliest agent rather than the most capable. A warm "Hi, how can I help?" is better than a confused attempt at fleet search.

Response generation

The response generator is the only node that calls the LLM with the full context. It combines everything the specialist agent prepared:

async def generate_response_node(state: dict) -> dict:
    bot_config = state.get("bot_config") or {}

    system_prompt = bot_config.get("system_prompt") or (
        f"You are a helpful assistant for {state.get('tenant', {}).get('name', 'our company')}. "
        "Be friendly, concise, and helpful."
    )

    # Build conversation from session history
    history = await session_manager.get_history(state["session_id"])
    messages = [{"role": m.role, "content": m.content} for m in history]
    messages.append({"role": "user", "content": state["message"]})

    # Agent-provided RAG chunks become part of the system prompt
    chunks = state.get("chunks", [])
    response_text = await llm_router.generate(
        messages, system_prompt, bot_config, chunks if chunks else None
    )

    return {"response": response_text, "history": messages}

Inside llm_router.generate, the RAG chunks are appended to the system prompt:

async def generate(self, messages, system_prompt, bot_config, chunks=None):
    full_system = system_prompt
    if chunks:
        context = "\n\n---\n\n".join(c.content for c in chunks)
        full_system += (
            "\n\nUse the following knowledge base excerpts to answer. "
            "If the information is not in the excerpts, say you don't have "
            "that specific information and suggest they contact the business directly."
            f"\n\n{context}"
        )

    model_map = {
        "claude-haiku": "claude-haiku-4-5-20251001",
        "claude-sonnet": "claude-sonnet-4-5-20250514",
        "claude-opus": "claude-opus-4-0-20250514",
    }
    raw_model = bot_config.get("model", "claude-haiku-4-5-20251001")
    model = model_map.get(raw_model, raw_model)

    response = await self.client.messages.create(
        model=model,
        max_tokens=bot_config.get("max_tokens", 1024),
        temperature=bot_config.get("temperature", 0.7),
        system=full_system,
        messages=messages,
    )
    return response.content[0].text

The "suggest they contact the business directly" fallback is important. When RAG returns no relevant chunks, the LLM knows it should not hallucinate an answer. This one instruction prevents the most common failure mode in RAG systems: confident fabrication when the knowledge base has a gap.

For real-time delivery, we stream the response with Server-Sent Events instead of waiting for the full completion:

from fastapi.responses import StreamingResponse

@router.post("/chat/stream")
async def chat_stream(req: ChatRequest):
    async def event_generator():
        # ... tenant resolution, governance, RAG ...

        async with client.messages.stream(
            model=model,
            max_tokens=max_tokens,
            system=system_prompt,
            messages=messages,
        ) as stream:
            async for text in stream.text_stream:
                yield f"data: {json.dumps({'type': 'token', 'content': text})}\n\n"

        yield f"data: {json.dumps({'type': 'done', 'conversation_id': cid})}\n\n"

    return StreamingResponse(event_generator(), media_type="text/event-stream")

The widget on the frontend reads these events with EventSource and renders tokens as they arrive. The perceived latency drops from seconds to milliseconds.

Putting it all together

Here is the complete graph definition:

from langgraph.graph import StateGraph, END, START

def create_chat_graph():
    graph = StateGraph(ChatState)

    # Add all nodes
    graph.add_node("resolve_tenant", resolve_tenant_node)
    graph.add_node("govern_input", govern_input_node)
    graph.add_node("classify_intent", classify_intent_node)
    graph.add_node("engagement", engagement_node)
    graph.add_node("fleet_search", fleet_search_node)
    graph.add_node("policy_search", policy_search_node)
    graph.add_node("quote", quote_node)
    graph.add_node("booking", booking_node)
    graph.add_node("needs", needs_node)
    graph.add_node("escalation", escalation_node)
    graph.add_node("generate_response", generate_response_node)
    graph.add_node("govern_output", govern_output_node)
    graph.add_node("save_message", save_message_node)

    # Entry: START → resolve tenant → governance input scan
    graph.add_edge(START, "resolve_tenant")
    graph.add_edge("resolve_tenant", "govern_input")

    # If governance denies the input, skip to save (no LLM call)
    graph.add_conditional_edges("govern_input", route_after_govern, {
        "save_message": "save_message",
        "classify_intent": "classify_intent",
    })

    # Route to specialist agent based on classified intent
    graph.add_conditional_edges("classify_intent", route_by_intent, {
        "engagement": "engagement",
        "fleet_search": "fleet_search",
        "booking": "booking",
        "policy_search": "policy_search",
        "quote": "quote",
        "needs": "needs",
        "escalation": "escalation",
    })

    # All agents (except escalation) → generate response
    for agent in ["engagement", "fleet_search", "policy_search",
                   "quote", "booking", "needs"]:
        graph.add_edge(agent, "generate_response")

    # Escalation skips LLM — fixed response, straight to save
    graph.add_edge("escalation", "save_message")

    # Response → output governance → save → done
    graph.add_edge("generate_response", "govern_output")
    graph.add_edge("govern_output", "save_message")
    graph.add_edge("save_message", END)

    return graph.compile()

To run the graph:

chat_graph = create_chat_graph()

result = await chat_graph.ainvoke({
    "message": "What SUVs do you have available?",
    "tenant_id": "acme-rentals",
    "session_id": "sess_abc123",
    "chunks": [],
    "sources": [],
    "escalated": False,
    "history": [],
})

print(result["response"])
print(result["intent"])        # "fleet_query"
print(result["current_agent"]) # "fleet"

The graph handles the full journey: resolve the tenant, scan the input, classify "What SUVs do you have available?" as fleet_query, route to the fleet agent, retrieve relevant vehicle chunks from the knowledge base, generate a response with Claude, scan the output, and save the conversation.

What's missing from this tutorial

This guide covers the multi-agent routing pattern. A production deployment needs several more layers:

Governance. Every message — inbound and outbound — should pass through a compliance layer that detects PII, enforces policies, and generates audit receipts. In the graph above, govern_input and govern_output are placeholders. In production, these call Tork's governance pipeline to scan every interaction before it reaches the LLM and before the response reaches the customer.

Session management. The history field in the state needs to be populated from a persistent session store. We use Upstash Redis with a 24-hour TTL and a 10-message rolling window. Without this, every message is context-free.

Rate limiting. Without it, a single user can exhaust your API budget in minutes. Rate limit per session, per tenant, and globally.

Multi-tenancy. The tenant and bot_config fields hint at this. In production, each tenant gets their own system prompt, model selection, knowledge base, and widget configuration. The same graph serves every tenant — the state carries the customisation.

Observability. Add tracing to every node. You need to know how long intent classification takes, which agent was selected, how many RAG chunks were retrieved, and what the LLM's token usage was. LangSmith integrates well with LangGraph for this.

If you want to see all of these concerns implemented together, Tork Chat is the production version of what this tutorial describes. We also wrote about the broader case for governed AI agents in The Agent Crisis, available free at tork.network.

Questions or building something similar? Reach out at tork.network.

Why Your AI Chatbot Needs Governance Before It Needs Features

TorkNetwork — Tue, 24 Mar 2026 11:45:22 +0000

You are about to deploy an AI chatbot. Your backlog has 40 items on it: better prompts, streaming responses, multi-language support, analytics dashboard, Slack integration. Governance is item 38, somewhere between "dark mode" and "maybe add a mascot."

This is the wrong order. And the consequences are not theoretical.

The feature trap

In March 2023, Samsung engineers pasted proprietary source code into ChatGPT on three separate occasions. The company banned the tool within weeks, but the data was already in OpenAI's training pipeline. In late 2023, Air Canada's chatbot invented a bereavement discount policy that did not exist — and a tribunal ruled the airline had to honour it. In 2024, a New York law firm submitted a court filing with six fabricated case citations generated by ChatGPT. The lawyers were sanctioned.

These are not edge cases from careless teams. These are what happens when capable AI is deployed without governance. The chatbot works. It sounds confident. It handles 80% of queries well. And then it stores a customer's ID number in plaintext, invents a policy, or leaks internal data — and the feature backlog becomes irrelevant because you are now managing a crisis.

Every team that has shipped an ungoverned AI chatbot believed they would "add governance later." Later does not arrive until after the incident.

What AI governance actually means

Governance is not a committee. It is not a PDF that legal signs off on. It is a middleware layer — running code that sits between the user and the LLM, inspecting every message in both directions.

Every input is scanned before the model sees it. Every output is checked before the customer sees it. Every interaction generates a cryptographic receipt that proves what happened.

Think of governance as a seatbelt, not a speed limit. A speed limit slows you down. A seatbelt lets you drive at full speed with a plan for when things go wrong. Governed AI is not slower AI. It is AI that you can defend, audit, and trust.

The 3 non-negotiable capabilities

1. PII detection

A customer types: "My ID number is 9502015800086 and my card is 4532-XXXX-XXXX-1234."

An ungoverned chatbot stores this in the conversation log, sends it to the LLM provider's API, and maybe writes it to an analytics database. That is three copies of sensitive data created in under a second.

A governed chatbot detects the PII before it leaves your infrastructure. The ID number is redacted. The card number is masked. The LLM receives the sanitised version. The original is never stored.

This is not optional. South Africa's POPIA Act requires that personal information be processed only for the purpose it was collected. Europe's GDPR requires data minimisation — you cannot store what you do not need. California's CCPA gives consumers the right to know what data you have collected. If your AI chatbot is hoovering up PII without detection, you are violating all of them simultaneously.

Real-time PII detection is the baseline. Everything else is built on top of it.

2. Audit receipts

When a regulator, a customer, or a lawyer asks "what did your AI say to this person on Tuesday at 14:32?", you need an answer. Not a log file. Not "we think it said something like this." A tamper-proof receipt.

An audit receipt is a record of every interaction: what the user sent, what the AI received (after redaction), what the AI responded, and what governance actions were taken. Each receipt has a unique ID, a timestamp, and is stored independently of the conversation log.

This is the difference between "we have logs" and "we have evidence." Logs can be edited. Receipts are cryptographically verifiable.

The Air Canada case would have gone differently if the company could have produced an audit trail showing that the chatbot's bereavement policy response was a hallucination that governance should have caught. Instead, they had no trail at all, and the tribunal treated the chatbot's statement as if it were company policy.

3. Policy enforcement

Your AI should have boundaries that are defined in code, not in hope.

Policy enforcement means defining what your AI can and cannot do: which topics it can discuss, which claims it can make, when it must escalate to a human, and what happens when it does not know the answer. These rules are evaluated on every message, not as a system prompt suggestion that the model might ignore.

A system prompt that says "do not discuss competitors" is a request. A governance policy that scans the output and blocks competitor mentions is enforcement. The difference matters when your chatbot decides to be helpful and recommends a rival's product.

Escalation triggers are part of policy enforcement. When a customer says "I want to speak to a manager" or "this is completely unacceptable," the governed response is not another AI-generated apology. It is a structured handoff to a human, with the conversation context attached. The ungoverned response is three more paragraphs of synthetic empathy that makes the customer angrier.

The cost of retrofitting

Adding governance after launch is not twice as hard. It is an order of magnitude harder.

Your database already has six months of unscanned conversations. Some contain PII. You do not know which ones. A full scan of historical data is a project in itself — and it reveals problems you now have to report under data protection law.

Your audit trail has gaps. For every conversation that happened before governance was added, you cannot prove what the AI said. If a customer dispute arises from that period, your legal position is "we don't know."

Your architecture was not designed for middleware. Adding an inspection layer between the user and the LLM means reworking your request pipeline, your streaming implementation, your error handling, and your tests. Features that were built assuming direct LLM access now need to account for governance latency, redaction, and denial responses.

And your customers have already formed trust expectations. If your chatbot has been freely accepting ID numbers for six months and suddenly starts redacting them, customers notice. The transition itself becomes a support issue.

Build governance into the foundation. Then build features on top of a system you can trust.

How we did it at Tork

At Tork, governance is not a wrapper around the AI. It is a node in the state machine.

Every message follows the same path: tenant resolution, then governance input scan, then intent classification, then agent routing, then response generation, then governance output scan, then storage. The LLM never sees raw PII. The response never reaches the customer without an output scan. Every step produces a receipt.

User message
  → Tenant resolution
  → Governance input scan (PII detect, policy check, receipt generated)
  → Intent classification
  → Specialist agent (fleet, policy, booking, etc.)
  → Response generation
  → Governance output scan (data leak check, policy check, receipt generated)
  → Customer receives response

If governance denies the input, the graph short-circuits. No LLM call, no agent routing, no response generation. The denial is recorded with a receipt, and the customer gets a safe fallback message. The system does less work, not more.

If governance is temporarily unreachable, the system degrades gracefully — messages are allowed through with a logged warning, and the governance scan is retried asynchronously. No single point of failure blocks the customer experience.

This architecture means governance cannot be bypassed by a new feature, a new endpoint, or a developer who forgets to add the middleware. It is structural, not procedural.

The practical checklist

Before you deploy any AI system that talks to customers, answer these seven questions:

Can it detect PII in real-time?
Not in a batch job overnight. In the request path, before the data is stored or sent to a third-party API.

Does it generate audit receipts?
Not log lines. Structured, immutable records with unique IDs that can be retrieved by conversation, by user, or by time range.

Can you prove what it said to a regulator?
If a data protection authority asks for the full interaction history for a specific customer, can you produce it within 72 hours? GDPR requires this.

Does it have escalation rules?
When the AI is out of its depth or the customer is frustrated, does it hand off to a human? Or does it keep generating responses and hoping for the best?

Is there a human override?
Can a supervisor intervene in a live conversation? Can you disable the AI for a specific tenant, a specific topic, or globally — without a deployment?

Is it compliant with local data protection law?
POPIA in South Africa. GDPR in Europe. CCPA in California. LGPD in Brazil. The law your AI needs to comply with depends on where your customers are, not where your servers are.

Can you turn it off in 5 seconds?
Not "start a deployment." Not "merge a PR." A kill switch. If the AI starts generating harmful content at scale, how fast can you stop it?

If you answered "no" to more than two of these, you are not ready to deploy. Fix governance first. The features can wait.

Start governed

We built Tork Chat because we needed a customer assistant that we could defend to a regulator, explain to a compliance officer, and trust with real customer data. The governance layer is not a premium add-on. It is the first thing that runs.

If you are building AI for customer-facing use cases, start with governance. Not because it is the responsible thing to do — though it is — but because retrofitting it later will cost you more in engineering time, legal exposure, and customer trust than building it right from the start.

Try Tork's governance-first approach at tork.network/chat. Free to start.

If you want the deeper thesis on why governed AI agents are the next frontier — and why most current deployments are dangerously ungovened — we wrote a book about it. The Agent Crisis is available free at tork.network.

Built by the Tork team. Governance-first AI for customer-facing deployments. tork.network

We Built a Multi-Agent AI Customer Assistant with Built-In Governance — Here's How

TorkNetwork — Tue, 24 Mar 2026 11:44:50 +0000

Most AI chatbots are a single model behind an API. One prompt, one response, no guardrails. That works for demos. It does not work when a customer asks about fleet availability, gets quoted a price, then wants to book — all in the same conversation. And it definitely does not work when that customer shares their ID number and you have no PII detection, no audit trail, and no compliance story.

We built Tork Chat to solve this. It is a multi-agent AI customer assistant with governance built into every message, not bolted on after. This post walks through how it works.

The architecture at a glance

The stack: Python 3.12, FastAPI, LangGraph, Anthropic Claude (Haiku for speed, Sonnet for depth), Supabase with pgvector for RAG, Upstash Redis for sessions, and Server-Sent Events for real-time streaming.

Every customer message passes through a state machine — not a single prompt chain — where specialist agents handle different parts of the conversation.

7 agents, one graph

We use LangGraph's StateGraph to orchestrate seven specialist agents. Each agent handles a specific customer intent: engagement (greetings, chitchat), fleet search (vehicle availability), policy lookup (insurance, deposits, fuel policy), quoting (pricing calculations), booking (reservation flow), needs assessment (open-ended questions), and escalation (hand-off to humans).

Here is the core graph definition:

from langgraph.graph import StateGraph, END, START

def create_chat_graph():
    graph = StateGraph(ChatState)

    # Add nodes
    graph.add_node("resolve_tenant", resolve_tenant_node)
    graph.add_node("govern_input", govern_input_node)
    graph.add_node("classify_intent", classify_intent_node)
    graph.add_node("engagement", engagement_node)
    graph.add_node("fleet_search", fleet_search_node)
    graph.add_node("policy_search", policy_search_node)
    graph.add_node("quote", quote_node)
    graph.add_node("booking", booking_node)
    graph.add_node("needs", needs_node)
    graph.add_node("escalation", escalation_node)
    graph.add_node("generate_response", generate_response_node)
    graph.add_node("govern_output", govern_output_node)
    graph.add_node("save_message", save_message_node)

    # Entry: resolve tenant, then governance scan
    graph.add_edge(START, "resolve_tenant")
    graph.add_edge("resolve_tenant", "govern_input")

    # If governance denies, skip straight to save
    graph.add_conditional_edges("govern_input", route_after_govern, {
        "save_message": "save_message",
        "classify_intent": "classify_intent",
    })

    # Route to specialist agent by intent
    graph.add_conditional_edges("classify_intent", route_by_intent, {
        "engagement": "engagement",
        "fleet_search": "fleet_search",
        "booking": "booking",
        "policy_search": "policy_search",
        "quote": "quote",
        "needs": "needs",
        "escalation": "escalation",
    })

    # Agents feed into response generation
    for agent in ["engagement", "fleet_search", "policy_search",
                   "quote", "booking", "needs"]:
        graph.add_edge(agent, "generate_response")

    # Escalation skips LLM — goes directly to save
    graph.add_edge("escalation", "save_message")

    # Response → output governance → save → done
    graph.add_edge("generate_response", "govern_output")
    graph.add_edge("govern_output", "save_message")
    graph.add_edge("save_message", END)

    return graph.compile()

The state that flows through this graph is a typed dictionary:

class ChatState(TypedDict):
    message: str
    tenant_id: str
    session_id: str
    intent: Optional[str]       # classified by Haiku
    current_agent: Optional[str]
    chunks: list                # RAG results
    input_receipt: Optional[dict]
    output_receipt: Optional[dict]
    response: Optional[str]
    escalated: bool

Intent classification uses Claude Haiku with temperature=0 and a constrained prompt that returns a single word. A regex pre-check catches obvious escalation patterns (requests for a human, excessive caps, frustration phrases) before the LLM is even called.

Governance is not optional

Every message — inbound and outbound — passes through Tork's governance pipeline before it reaches the LLM. This is not content moderation. It is structured compliance: PII detection with automatic redaction, policy violation scanning, and cryptographic audit receipts for every interaction.

class TorkGovernance:
    async def scan_input(self, content, tenant_id, session_id):
        return await self._scan(content, tenant_id, session_id, direction="input")

    async def scan_output(self, content, tenant_id, session_id):
        return await self._scan(content, tenant_id, session_id, direction="output")

    async def _scan(self, content, tenant_id, session_id, direction):
        payload = {
            "content": content,
            "mode": "scan",
            "agent_id": "tork-chat",
            "agent_role": "customer-assistant",
            "session_id": session_id,
            "tenant_id": tenant_id,
            "direction": direction,
        }
        resp = await client.post(self.govern_url, json=payload, headers=headers)
        data = resp.json()
        return GovernanceResult(
            action=data.get("action", "allow"),     # allow, redact, or deny
            content=data.get("redacted_content", content),
            receipt_id=data.get("receipt_id", ""),
            pii_detected=data.get("pii_detected", []),
        )

Three possible outcomes: allow (pass through), redact (PII stripped, original never reaches the LLM), or deny (message blocked entirely). Every scan produces a receipt ID that is stored alongside the conversation in the database. If a regulator asks "what did the AI see and what did it respond?", the answer is a database query away.

The governance node sits at position two in the graph — right after tenant resolution and before anything else. If governance denies the input, the graph short-circuits to save_message without ever calling the LLM. The denial is still recorded.

SSE streaming for real-time responses

Nobody wants to stare at a spinner for three seconds. We use Server-Sent Events to stream tokens as they are generated:

@router.post("/chat/stream")
async def chat_stream(req: ChatRequest):
    async def event_generator():
        yield _sse_event("typing", {"status": "thinking"})

        # ... tenant resolution, governance, RAG ...

        async with llm_router.client.messages.stream(
            model=model,
            max_tokens=max_tokens,
            system=system_prompt,
            messages=messages,
        ) as stream:
            async for text in stream.text_stream:
                yield _sse({"type": "token", "content": text})

        yield _sse({"type": "governance", "input_receipt": {...}, "output_receipt": {...}})
        yield _sse({"type": "done", "conversation_id": conversation_id})

    return StreamingResponse(event_generator(), media_type="text/event-stream")

The event stream carries five event types: token (each text chunk), sources (RAG retrieval results), governance (the input and output receipt metadata), typing (UI indicators), and done (the conversation ID for persistence). The widget on the frontend reads these events and renders tokens as they arrive. The governance metadata arrives after the full response, so the widget can display a "governed" badge without blocking the stream.

Multi-tenant by design

Tork Chat is multi-tenant from the ground up. Each tenant gets their own bot configuration (system prompt, model selection, temperature), knowledge base (RAG scoped by tenant ID in Supabase), and widget styling. Tenant configs are cached in Redis with a 5-minute TTL.

This means the same engine that powers a vehicle rental assistant can also power a property management chatbot or a legal intake bot — each with their own personality, knowledge, and governance rules.

What we learned

Intent classification accuracy matters more than response quality. A wrong classification routes the customer to the wrong agent, which retrieves the wrong context, which generates a plausible but incorrect answer. We found that Claude Haiku at temperature zero with a tightly constrained system prompt ("respond with ONLY the intent word") achieves reliable classification. Adding a regex pre-check for escalation patterns caught edge cases the LLM missed — particularly frustrated customers using all-caps or demanding a human.

Escalation detection saves your reputation. The escalation agent does not generate a response. It produces a structured handoff message with the conversation summary and immediately saves. No LLM in the loop for angry customers. This was a deliberate design choice after observing that LLMs tend to be overly apologetic when they should be connecting the customer to a real person.

Governance is a feature, not a burden. Every tenant we have spoken to asks about compliance within the first three questions. PII detection and audit trails are not "nice to have" — they are table stakes for deploying AI in customer-facing roles. Building governance into the graph (rather than wrapping it around the API) means it cannot be bypassed. It is a node in the state machine, not middleware that can be skipped.

Graceful degradation is non-negotiable. If governance is unreachable, the message is allowed through with a logged warning. If Redis is down, sessions fall back to in-memory. If RAG returns no chunks, the LLM is instructed to say it does not have the information and suggest contacting the business directly. Every external dependency has a fallback path.

Real-world deployment

Tork Chat is currently deployed in the vehicle rental industry, handling fleet availability queries, pricing questions, booking flows, insurance and deposit policies, and after-hours support. The system runs 24/7 and escalates to human agents when it detects frustration or explicit handoff requests.

The widget is embeddable on any website via a script tag, and new tenants can onboard at chat.tork.network/onboard.

Try it

You can see Tork Chat in action at tork.network/chat.

If you are interested in the broader thesis behind governed AI agents — why compliance-first design is the next frontier for AI deployment — we wrote a book about it. The Agent Crisis is available free at tork.network.

Built by the Tork team. Questions, feedback, or want to deploy Tork Chat for your business? Reach out at tork.network.

Add AI Governance to Your Agent in 5 Minutes with Tork SDK

TorkNetwork — Wed, 04 Mar 2026 07:43:27 +0000

---
title: "Add AI Governance to Your Agent in 5 Minutes with Tork SDK"
description: "Learn how to implement comprehensive AI governance including PII detection, policy enforcement, and compliance monitoring in your AI agents using Tork SDK in just 5 minutes."
tags: [ai, governance, security, mcp]
---

# Add AI Governance to Your Agent in 5 Minutes with Tork SDK

AI agents are transforming business operations, but with great power comes great responsibility. As AI agents handle increasingly sensitive data and make autonomous decisions, implementing proper governance isn't just a nice-to-have—it's essential for compliance, security, and ethical AI deployment.

The challenge? Traditional governance solutions are complex, time-consuming to implement, and often require extensive infrastructure changes. What if you could add comprehensive AI governance to your existing agent in just 5 minutes?

## Why AI Agents Need Governance

Modern AI agents process vast amounts of data, interact with users, and make decisions that can impact businesses and individuals. Without proper governance:

- **Sensitive data exposure**: Agents may inadvertently process or leak PII, financial data, or healthcare information
- **Compliance violations**: Failure to meet GDPR, HIPAA, SOC 2, or other regulatory requirements
- **Audit trail gaps**: Lack of visibility into agent decisions and data handling
- **Policy drift**: No mechanism to enforce organizational AI policies consistently

The solution? Implementing governance that monitors, controls, and audits your AI agent's behavior in real-time.

## Enter Tork Network: Governance Made Simple

[Tork Network](https://tork.network) provides an AI governance platform that detects PII in under 1ms, enforces policies across 79+ compliance frameworks, and provides cryptographic compliance receipts—all through simple SDK integration.

Let's walk through implementing comprehensive governance in your AI agent.

## Step 1: Install the Tork SDK (30 seconds)

Choose your preferred language and install the SDK:

### Python

bash
pip install tork


### JavaScript/TypeScript

bash
npm install @tork/sdk


### Go

bash
go get github.com/tork-network/tork-go


## Step 2: Initialize Your Governance Client (1 minute)

Set up your Tork client with your API key:

### Python Example

python
from tork import TorkClient
import os

Initialize client

client = TorkClient(
api_key=os.getenv("TORK_API_KEY"),
environment="production" # or "sandbox" for testing
)


### JavaScript Example

javascript
import { TorkClient } from '@tork/sdk';

const client = new TorkClient({
apiKey: process.env.TORK_API_KEY,
environment: 'production'
});


## Step 3: Add Pre-Processing Governance (2 minutes)

Implement governance checks before your agent processes user input:

python
async def process_user_input(user_message: str, user_id: str):
# Step 1: Detect and classify sensitive data
governance_result = await client.analyze_content(
content=user_message,
user_id=user_id,
policies=[
"pii-detection",
"gdpr-compliance",
"data-minimization"
]
)

# Step 2: Check if content violates policies
if governance_result.has_violations():
    # Handle policy violations
    for violation in governance_result.violations:
        print(f"Policy violation: {violation.policy_name}")
        print(f"Detected: {violation.detected_patterns}")

    # Return sanitized content or block request
    if governance_result.risk_level == "HIGH":
        return {"error": "Content blocked due to policy violation"}
    else:
        # Use sanitized version
        user_message = governance_result.sanitized_content

# Step 3: Proceed with agent processing
agent_response = await your_agent_process(user_message)

return agent_response


## Step 4: Add Post-Processing Governance (1 minute)

Ensure your agent's responses also comply with governance policies:

python
async def validate_agent_response(response: str, context: dict):
# Analyze agent output for compliance
output_analysis = await client.analyze_output(
content=response,
context=context,
compliance_frameworks=["SOC2", "GDPR", "HIPAA"]
)

# Generate compliance receipt
compliance_receipt = await client.generate_receipt(
    transaction_id=context.get("transaction_id"),
    analysis_result=output_analysis
)

# Log for audit trail
await client.log_interaction(
    user_id=context.get("user_id"),
    input_analysis=context.get("input_analysis"),
    output_analysis=output_analysis,
    compliance_receipt=compliance_receipt
)

return {
    "response": output_analysis.sanitized_content,
    "compliance_receipt": compliance_receipt.signature,
    "risk_score": output_analysis.risk_score
}


## Step 5: Complete Integration Example (1 minute)

Here's a complete example showing governance integration with a typical AI agent:

python
import asyncio
from tork import TorkClient
from datetime import datetime

class GovernedAIAgent:
def init(self, tork_api_key: str):
self.tork = TorkClient(api_key=tork_api_key)

async def handle_request(self, user_message: str, user_id: str):
    transaction_id = f"txn_{datetime.now().isoformat()}"

    try:
        # Pre-processing governance
        input_analysis = await self.tork.analyze_content(
            content=user_message,
            user_id=user_id,
            transaction_id=transaction_id,
            policies=["pii-detection", "content-safety", "gdpr-compliance"]
        )

        # Block high-risk content
        if input_analysis.risk_level == "HIGH":
            return {
                "error": "Request blocked for policy violation",
                "violation_id": input_analysis.violation_id
            }

        # Process with your AI agent
        processed_input = input_analysis.sanitized_content
        agent_response = await self.generate_response(processed_input)

        # Post-processing governance
        output_analysis = await self.tork.analyze_output(
            content=agent_response,
            transaction_id=transaction_id,
            compliance_frameworks=["SOC2", "GDPR"]
        )

        # Generate cryptographic compliance receipt
        receipt = await self.tork.generate_receipt(
            transaction_id=transaction_id,
            input_analysis=input_analysis,
            output_analysis=output_analysis
        )

        return {
            "response": output_analysis.sanitized_content,
            "governance": {
                "risk_score": output_analysis.risk_score,
                "compliance_receipt": receipt.hmac_signature,
                "frameworks_validated": receipt.frameworks
            }
        }

    except Exception as e:
        # Log governance failures
        await self.tork.log_error(
            transaction_id=transaction_id,
            error=str(e),
            user_id=user_id
        )
        raise

async def generate_response(self, message: str):
    # Your existing AI agent logic here
    return f"Agent response to: {message}"

Usage

agent = GovernedAIAgent(tork_api_key="your_api_key")
result = await agent.handle_request(
user_message="Hello, my SSN is 123-45-6789",
user_id="user_123"
)
print(result)


## Real-Time Monitoring and Alerts

Tork SDK automatically provides real-time monitoring capabilities:

python

Set up policy alerts

await client.configure_alerts(
policies=[
{
"name": "high-risk-pii",
"trigger": "risk_score > 0.8",
"action": "block_and_alert"
},
{
"name": "compliance-violation",
"trigger": "gdpr_violation OR hipaa_violation",
"action": "log_and_sanitize"
}
],
webhook_url="https://your-app.com/governance-alerts"
)


## Advanced Features

### Multi-Protocol Support
Tork supports multiple communication protocols including MCP (Model Context Protocol), enabling governance across different agent architectures:

python

MCP integration

mcp_client = client.create_mcp_handler()
await mcp_client.register_governance_middleware()


### Regional Compliance
Handle global deployments with regional compliance variants:

python

Configure for different regions

governance_config = {
"eu_users": ["GDPR", "EU_AI_Act"],
"us_users": ["CCPA", "SOC2"],
"global": ["ISO27001"]
}

result = await client.analyze_with_regional_policies(
content=user_message,
user_region="EU",
config=governance_config
)


## Monitoring and Compliance Dashboard

Once implemented, you can monitor your agent's governance metrics through the [Tork dashboard](https://tork.network/demo), including:

- Real-time PII detection rates
- Policy violation trends
- Compliance framework adherence
- Risk score distributions
- Audit trail completeness

## Getting Started

Ready to add governance to your AI agent? Here's how to begin:

1. **Sign up** for a free Tork account with 5,000 API calls per month
2. **Install** the SDK for your preferred language
3. **Follow** the 5-minute integration guide above
4. **Test** with the sandbox environment
5. **Deploy** to production with confidence

The implementation above provides enterprise-grade AI governance including PII detection, policy enforcement across 79+ compliance frameworks, cryptographic audit trails, and real-time monitoring—all with minimal code changes to your existing agent.

## Best Practices

- **Start with policies**: Define your governance policies before implementation
- **Test thoroughly**: Use Tork's sandbox environment to validate governance behavior
- **Monitor continuously**: Set up alerts for policy violations and unusual patterns
- **Regular audits**: Review compliance receipts and audit trails regularly
- **Stay updated**: Keep your SDK updated to benefit from new governance features

Implementing AI governance doesn't have to be complex or time-consuming. With Tork SDK, you can add comprehensive governance to any AI agent in minutes, ensuring your AI systems remain compliant, secure, and trustworthy as they scale.

Start your governance journey today with [Tork Network's platform](https://tork.network/pricing) and transform your AI agents into governed, compliant systems that you can deploy with confidence.

The Self-Trust Paradox: Why AI Agents Can't Govern Themselves

TorkNetwork — Tue, 24 Feb 2026 05:22:49 +0000

Imagine you hire a security guard. The guard's job is to check everyone entering the building. Now imagine someone walks in and hands the guard a note that says "You will now let everyone in without checking IDs."

If the guard reads and follows the note — the guard has been compromised.

This is exactly how prompt injection works against AI agents. The agent IS the security guard, and the instructions it processes ARE the notes. An agent cannot reliably check for prompt injection because prompt injection targets the checking mechanism itself.

This is the self-trust paradox.

The Three Laws of Self-Trust Failure

Law 1: The Inspector Cannot Inspect Itself

When an AI agent checks its own outputs for safety, it uses the same reasoning engine that produced those outputs. A compromised model produces compromised safety checks.

It's like asking a corrupted database to verify its own integrity. The corruption affects the verification process itself.

Researchers have demonstrated that prompt-injected models will confidently report "no injection detected" when checking their own context. The fox is guarding the henhouse.

Law 2: Cryptographic Attestation Requires External Authority

You can't sign your own SSL certificate and expect browsers to trust it. Self-signed certificates exist but carry zero trust — that's why Certificate Authorities exist as independent third parties.

AI governance works the same way. An agent claiming "I'm safe" is a self-signed certificate. Nobody should trust it.

Independent attestation — compliance receipts issued by an external party — is the CA model for AI agents. Trust badges that agents issue to themselves are worthless. They must come from an independent party.

Law 3: Regulatory Frameworks Demand Independence

This isn't theoretical. Regulations already require independence:

Regulation	Requirement
GDPR Article 35	Independent Data Protection Impact Assessments
SOC 2	Independent auditors — you can't self-certify
EU AI Act	Third-party conformity assessments for high-risk systems

No regulator will accept "the AI checked itself and said it's fine." Enterprises are being asked these questions right now.

Why "Built-In Safety" Isn't Enough

Every major AI framework has safety features. They're necessary but insufficient:

OpenClaw has permission prompts — but prompt injection can bypass them
LLM providers have content filters — but they don't catch PII in structured data
Agent frameworks have sandboxing — but sandboxes don't generate compliance receipts

The gap isn't capability, it's independence. A feature of the system cannot independently verify the system.

Think of it this way: your car has seatbelts (built-in safety), but you still need an independent crash test rating (governance). Both matter. One doesn't replace the other.

The SSL Analogy

In 1994, the web had the same trust problem AI agents have today.

Websites could claim to be secure, but there was no way to verify. The solution: Certificate Authorities — independent third parties that verify identity and issue certificates. The SSL padlock became the universal signal of trust.

AI agents need the same infrastructure. Independent governance that issues verifiable attestation.

A "Protected by Tork Network" badge means: this agent's traffic is independently monitored, PII is detected and redacted, and compliance receipts exist for every interaction. It's the SSL padlock for AI agents.

What Independent Governance Actually Means

Independent means: not part of the agent, not part of the LLM provider, not part of the framework.

Tork Network sits between the agent and the world — inspecting, protecting, attesting:

Every interaction generates a compliance receipt with a cryptographic hash
PII detection happens at ~1ms — fast enough that agents don't slow down
TORKING-X scores quantify governance quality — like a credit score for AI trustworthiness
Trust badges are cryptographically verifiable, not self-issued
Works across ALL frameworks: OpenClaw, Nanobot, AstrBot, PicoClaw, ZeroClaw, Lobu (integration guides)

The Network Effect of Trust

When one agent has a trust badge, others without badges look suspicious. This is the same dynamic that drove SSL adoption: once some sites had padlocks, users started avoiding sites without them.

We recently scanned 500 ClawHub skills — 10% were dangerous, 20% were risky. 284 earned trust badges. The leaderboard is live at tork.network/leaderboard.

By 2028, ungoverned AI agents will be treated like HTTP websites — functional but untrusted. The question isn't whether independent governance will become standard. It's whether you'll be early or late.

Start now

# Scan any skill directory — free, no account needed
npx tork-scan ./my-skill

→ Add governance in 5 minutes
→ Get your trust badge
→ Integration guides for your framework
→ HN discussion

Why VirusTotal Isn't Enough for AI Agent Security"

TorkNetwork — Tue, 24 Feb 2026 05:22:13 +0000

VirusTotal scans files. AI agents need runtime governance. Here's what's missing — and how to fix it."
tags: security, ai, opensource, devops
cover_image: https://tork.network/og-image.png
canonical_url: https://tork.network/blog/virustotal-not-enough
900+ malicious skills detected in ClawHub. 135,000+ exposed OpenClaw instances across 82 countries. Microsoft, CrowdStrike, Palo Alto Networks, and Kaspersky all issued formal security advisories.
The AI agent ecosystem has a security crisis.
The response so far
OpenClaw — the largest open-source AI agent framework with 160K+ stars — partnered with VirusTotal to scan skills in ClawHub, their community registry. It's a reasonable first step. VirusTotal is excellent at what it does: scanning files against 70+ antivirus engines to detect known malware signatures.
But here's the problem: AI agent security isn't a file scanning problem.
What VirusTotal does well
Credit where it's due. VirusTotal is world-class at:

Signature-based malware detection across 70+ engines
Static file analysis and hash lookups
Known threat identification with massive databases
Community-driven threat intelligence

For traditional malware, it's one of the best tools available. But AI agents aren't traditional software.
The 6 gaps VirusTotal can't fill

No Runtime Governance VirusTotal scans files before execution. Once an agent is running, there's no protection. A skill that passes static scanning can still exfiltrate data at runtime — and many do.
No PII Detection or Redaction Your user sends their SSN through an agent. VirusTotal has no concept of PII. The data flows through completely unprotected. Runtime PII detection catches this in ~1ms.
No Compliance Receipts When auditors ask "prove this agent handled data correctly," VirusTotal has nothing to show. You need cryptographic compliance receipts for every interaction — a provable audit trail.
No Prompt Injection Defense Prompt injection is the #1 attack vector for AI agents. An attacker can override an agent's safety instructions through crafted input. Static file scanning can't detect runtime prompt manipulation.
No Novel Attack Detection Signature databases only catch known threats. The AI agent ecosystem sees new attack patterns daily. Novel attacks slip through until signatures are updated — which can take weeks.
No Governance Attestation There's no way to prove an agent is governed. No badge, no certificate, no verifiable claim. Without attestation, users and enterprises have no trust signal. The Self-Trust Paradox Here's the deeper issue: AI agents cannot govern themselves for the same reason you can't audit your own books. The entity checking for threats can be compromised by those same threats. Prompt injection targets the checking mechanism itself. An agent checking its own context for injection can be fooled by that same injection. SSL certificates work because Certificate Authorities are independent. AI governance needs the same model — independent third parties that verify and attest. I wrote a full exploration of this: The Self-Trust Paradox: Why AI Agents Can't Govern Themselves What independent governance looks like We built Tork Network to fill these gaps:

Runtime PII detection at ~1ms — doesn't slow your agent
Cryptographic compliance receipts — provable audit trail for every interaction
Trust badges — verifiable governance attestation, like the SSL padlock
TORKING-X scoring — quantified governance quality (like credit scores for AI agents)
19 risk pattern detection via tork-scan — catches what signatures miss

It works across ALL agent frameworks, not just OpenClaw. We have integration guides for 6 platforms.
We scanned 500 ClawHub skills
We didn't just build the theory — we tested it. We ran tork-scan on 500 ClawHub skills:

200 (40%) scored SAFE
150 (30%) scored CAUTION
100 (20%) scored RISKY
50 (10%) scored DANGEROUS

The dangerous ones included reverse shells, credential harvesting, C2 domain connections, and typosquats with innocent names hiding malicious code.
Full results and leaderboard →
Try it yourself
bash# Scan any skill directory — free, no account needed
npx tork-scan ./my-skill
→ Get started free
→ Full writeup: We Scanned 500 ClawHub Skills
→ Integration guides for 6 frameworks
VirusTotal is great at what it does. It just wasn't built for this. AI agents need independent, runtime governance — and now they have it.