Briefing document for Jimmy. The client wants to discuss guardrails, deployment strategies, observability, and practical architectures for AI agents. No NDA in place – this covers capabilities and positioning only, no implementation details.
Call Agenda
- Guardrails for AI agents (safety, policy enforcement, hallucination control)
- Deployment strategies for AI agents (cloud / container / orchestration)
- Observability and monitoring
- Practical architectures and best practices
1. Guardrails for AI Agents
What the client is worried about
They want to know: how do you stop an AI agent from doing something dangerous, leaking data, following injected instructions, or producing harmful content?
What WorkingAgents provides
WorkingAgents enforces guardrails at three checkpoints on every agent action – before, during, and after execution. This is not a monitoring layer that alerts after the fact. It’s an enforcement layer that blocks bad actions before they happen.
Pre-execution guardrails:
- Input validation before any tool runs
- Prompt injection detection – blocks “ignore all previous instructions” and similar manipulation patterns
- SQL injection, path traversal, and command injection scanning
- Tool argument validation against expected schemas
- Budget and rate limit checks before expensive operations
Real-time guardrails:
- Human-in-the-loop approval for high-risk operations – the system can pause and ask “the agent wants to delete a production record – approve or deny?”
- Rate limiting per user, per tool, per time window – prevents runaway agent loops from burning through API budgets
- Sequence detection – flags suspicious patterns like reading sensitive data followed by sending it externally
Post-execution guardrails:
- Output inspection before results reach the agent
- PII detection and redaction across 20+ categories (SSNs, credit cards, emails, phone numbers, addresses)
- Content safety filtering with configurable thresholds
- Topic filtering – block agents from providing medical advice, legal counsel, or financial recommendations if that’s your policy
- Custom rules – your policies, your logic, enforced at the gateway
On hallucination control specifically
WorkingAgents does not claim to eliminate hallucinations – no governance layer can, because hallucinations are a property of the model. What WorkingAgents does:
- Grounds agent actions in structured tool results rather than letting agents generate free-form actions. An agent that must call a CRM tool to get customer data is less likely to hallucinate that data than one that generates it from memory.
- Knowledge base integration – agents can retrieve relevant context from a governed knowledge base before answering, reducing the model’s need to generate facts from training data.
- Audit trails on every action – when an agent does hallucinate or produce incorrect output, the full chain of reasoning, tool calls, and inputs is logged. You can trace exactly what went wrong.
- Model routing – route complex queries to more capable (and less hallucination-prone) models, while sending simple queries to cheaper, faster ones.
How to talk about it on the call
“We enforce guardrails at three checkpoints: before, during, and after every agent action. Pre-execution blocks injection attacks and validates inputs. Real-time monitoring can pause for human approval on high-risk operations. Post-execution redacts PII and filters unsafe content before it leaves the system. Every check is configurable – your policies, your thresholds.”
“On hallucinations: we can’t eliminate them – that’s a model property. What we do is ground agents in structured data through tool calls and knowledge retrieval, and log every step so when something goes wrong, you can trace exactly what happened and why.”
2. Deployment Strategies
What the client is worried about
Where does this run? Do they have to send data to a third party? Can it run in their cloud, their VPC, on-premises?
What WorkingAgents provides
Self-hosted, zero data egress. WorkingAgents deploys inside the customer’s environment. Their VPC, their data center, their air-gapped network. The platform orchestrates workloads without extracting data. No data leaves the customer’s perimeter unless they explicitly configure it to (e.g., calling an external LLM API).
One instance per customer. No multi-tenancy. No shared infrastructure. Each customer runs their own WorkingAgents instance on their own server. Their data never touches another customer’s environment.
Deployment options:
- Cloud VPC (AWS, GCP, Azure – any cloud)
- On-premises servers
- Air-gapped environments (defense, healthcare, finance)
- Hybrid – governance layer on-premises, LLM API calls routed through controlled egress
Works with any agent framework. Claude Code, OpenAI Codex, Gemini CLI, LangChain, CrewAI, Anthropic Agent SDK, or custom agents. WorkingAgents connects via standard protocols (MCP, A2A, REST, WebSocket). The governance layer sits between the agents and the tools/models they access. No changes to the agent framework required.
LLM Gateway. WorkingAgents can proxy agent-to-LLM traffic, giving visibility into what agents send to model providers. Agents point their API base URL at WorkingAgents instead of the provider directly. The gateway logs, scans, and forwards. This is optional – enterprises that want visibility into agent-to-model conversations enable it; those that don’t can skip it.
How to talk about it on the call
“WorkingAgents runs in your environment. Your VPC, your servers, your air-gapped network. No data leaves your perimeter. One instance per customer – no shared infrastructure.”
“It works with whatever agents you’re already using or planning to use. Claude Code, Codex, LangChain, custom agents – we connect via MCP, the industry-standard protocol. The governance layer sits between your agents and your systems. No changes to the agent code required.”
3. Observability and Monitoring
What the client is worried about
They want to know: what can we see? When something goes wrong, can we trace it? Can we prove to a regulator what the AI did?
What WorkingAgents provides
Every agent action, tool call, model request, and guardrail evaluation is logged with full context:
- Who – which user triggered the action, which agent was acting on their behalf
- What – which tool was called, with what arguments, and what result was returned
- When – precise timestamps on every action
- Which model – which LLM was used, how many tokens were consumed, what it cost
- What the guardrails did – which checks passed, which failed, what was blocked or redacted
Cost attribution. Token-level cost tracking by user, by team, by model, by workflow. You know exactly how much each agent is spending and where.
Latency tracking. P99/P90/P50 latency per endpoint, per tool, per model. Identify bottlenecks before they become outages.
Audit trail. Immutable logs with payload hashing for tamper detection. When a regulator asks “what did the AI do with patient data?”, the answer is in the trail – complete, timestamped, and verifiable.
Request-level inspection. Full prompt and response logging (optional, configurable). See exactly what was sent to the model and what came back. Useful for debugging, compliance, and incident response.
How to talk about it on the call
“Every action is logged: who triggered it, what tool was called, what arguments were sent, what came back, which model was used, how much it cost, and what the guardrails did. The audit trail is immutable and tamper-evident.”
“If a regulator asks ‘what did your AI agent do on March 15th at 2:47 PM?’, you can show them the complete chain: the user who initiated it, the agent that acted, every tool call in sequence, every model interaction, every guardrail check. Full traceability.”
4. Practical Architectures and Best Practices
What the client is worried about
How does this fit into a real enterprise architecture? What does the integration look like? What are the patterns that work?
Architecture Overview
Users / Applications
|
v
AI Agents (Claude Code, Codex, LangChain, custom)
|
v
WorkingAgents Gateway (customer's VPC)
|
+-- AI Gateway ---------> LLM Providers (250+ models)
| (routing, failover, cost control)
|
+-- MCP Gateway --------> Enterprise Tools & Data
| (permissions, guardrails, audit)
|
+-- Agent Gateway ------> Workflow Orchestration
(retries, timeouts, escalation)Key Architecture Patterns
Pattern 1: Gateway between agents and tools. The most common pattern. Agents connect to WorkingAgents via MCP. WorkingAgents checks permissions, enforces guardrails, executes the tool, scans the result, and returns it. The agent never talks to enterprise systems directly.
Pattern 2: LLM proxy for model governance. Agents point their API base URL at WorkingAgents instead of the model provider directly. WorkingAgents logs the full conversation, scans for PII before it leaves the perimeter, enforces cost limits, and forwards to the model. Optional but valuable for enterprises that need visibility into agent-to-model traffic.
Pattern 3: Multi-agent orchestration with permission boundaries. Different agents get different permissions based on the user they’re acting for. A sales agent sees CRM tools. An engineering agent sees deployment tools. Neither sees the other’s data. Permission boundaries are enforced at the gateway, not in the agent code.
Pattern 4: Retrofit governance onto existing deployments. Enterprises that already have AI agents running on OpenAI, Anthropic, or open-source models can add WorkingAgents as a governance layer without rearchitecting. The gateway wraps existing deployments. Relevant for companies approaching the EU AI Act deadline (August 2, 2026).
Best Practices We Recommend
- Least-privilege by default. Agents get the minimum permissions needed for their role. Temporary access grants (TTL-based) for elevated operations that expire automatically.
- Human-in-the-loop for irreversible actions. Deleting data, sending external emails, modifying production systems – pause and ask a human.
- Route by cost, not by default. Simple queries to cheap models. Complex reasoning to capable models. Don’t send every question to the most expensive model.
- Log everything, redact PII. Full audit trail, but redact sensitive data before it leaves the system. The audit shows what happened without exposing the data itself.
- Separate the governance layer from the agent framework. Governance should work regardless of which agent framework or model provider you use. Tying governance to one vendor creates the same lock-in problem agents were supposed to solve.
How to talk about it on the call
“The basic pattern: agents connect to WorkingAgents via MCP, the industry-standard protocol. We sit between the agents and your systems. Permissions, guardrails, and audit happen at the gateway. The agents don’t change.”
“The architecture is vendor-neutral. It works with any model provider and any agent framework. You’re not locking your governance infrastructure to one vendor.”
“For companies that already have AI agents in production, we can add governance without rearchitecting. We wrap what you already have.”
Objections and Responses
“We’re already using [Anthropic/OpenAI/Google]’s built-in safety features.”
“Those safety features cover the model’s behavior. They don’t cover what happens when the model interacts with your systems – your databases, your APIs, your customer data. That’s the governance gap we fill.”
“Why can’t we just build this ourselves?”
“You can. Most enterprises estimate 6-12 months of engineering to build and maintain a production-grade governance layer. We’re a deployment away from production. The question is whether governance is your core competency or ours.”
“How does this affect agent performance?”
“Permission checks are sub-millisecond. The LLM API call itself takes seconds. Guardrail scanning is microsecond-level regex and pattern matching. The governance overhead is noise compared to network latency.”
“What about the EU AI Act?”
“Non-high-risk AI system obligations take effect August 2, 2026. Deployers – not just model providers – carry compliance obligations. WorkingAgents provides the audit trails, permission enforcement, and guardrails that deployers need to demonstrate compliance.”
Things NOT to Say (No NDA)
- Do not describe specific module names, file paths, or code architecture
- Do not mention Elixir/OTP, BEAM, GenServer, or other implementation details
- Do not describe the database layer, access control key implementation, or encryption specifics
- Do not name specific tool counts (say “80+” not “86”)
- Do not share pricing unless James has approved specific numbers for this prospect
- Do not mention other prospects or design partners by name
- Do not share internal feasibility assessments or competitive analyses
Stick to: capabilities, architecture patterns, deployment options, guardrail categories, and the value proposition. If they ask for implementation details, the answer is: “We’d love to do a technical deep dive – let’s set that up as a next step.”
Closing the Call
Suggest one of:
- Technical deep dive with their engineering team (requires NDA)
- Pilot identification workshop to pick a specific use case for a proof-of-concept
- Architecture review of their current AI deployment to identify governance gaps
Contact: [email protected] | workingagents.ai