THE PRODUCT
Vantage Workspace.
The platform we built because the alternative — assembling an “agentic AI stack” out of twelve vendors with twelve identities and twelve audit logs — wasn't a purchase, it was a project.
This page documents what's in it, how it's built, and where the architectural decisions came from.
THE PLATFORM
Six pillars. One identity.
Most “AI for the enterprise” products ship a chatbot. Vantage Workspace ships the productivity stack the chatbot needs to be useful. Email, files, chat, meetings, documents — and an AI agent layer that operates across all five. The point is not the chatbot. The point is the integration.
Email.
A first-class email client built into the platform, not a connector. Threaded inbox, smart folders, signature management, scheduled send, snooze. SMTP, IMAP, and Microsoft 365 / Google Workspace native sync — all under your tenant identity, all logged into the same audit trail as the rest of the platform. The AI agent can read, draft, and send email on behalf of the user (with the user's per-action consent) and every send is attributed. No shared service account. No “email bot” that bypasses the user's identity.
The control surface includes per-user signature templates, per-folder retention policies, and per-thread classification (e.g. “client communication”, “internal”, “financial”), each of which feeds the audit log and the compliance evidence pipeline.
Files.
Object-store-backed file system with versioning, ACLs, and per-file audit history. S3-compatible API for programmatic access. Drag-and-drop upload, in-browser preview for the standard formats (PDF, DOCX, XLSX, images), and a permission model that integrates with the SSO layer rather than maintaining its own. Encryption at rest (AES-256-GCM), encryption in transit (TLS 1.3, mTLS for inter-service traffic).
The AI agent can read files, summarise them, and (with explicit per-file consent) write them. Every read is logged. Every write produces a versioned record that can be rolled back.
Chat.
Channel-based team chat, threaded replies, direct messages, message reactions, file attachments. Integrates with the same identity layer as everything else — a chat message and an email reply from the same user are tied to the same audit trail.
The AI agent can be invoked inside any channel by mention. The agent's reply is attributed (not anonymised), the prompt is logged, and the response is graded by the post-response checker before it's posted. If the checker flags a response as policy-violating, the message is held in moderation rather than sent.
Meetings.
Video conferencing built around the same identity model. WebRTC under the hood, recording stored in the file pillar (versioned, ACL'd), transcription processed by an in-platform model (not sent to a third party). Calendar integration via CalDAV / Exchange / Google Calendar.
The AI agent can join a meeting (with the host's consent), transcribe, summarise, extract action items, and post them into the relevant chat channel — all under the host's identity and audit trail. Recordings are retained per the per-tenant retention policy.
Documents.
Collaborative document editing. Real-time co-editing, comment threads, suggestion mode, version history. Markdown-first internally; exports to DOCX, PDF, HTML. Templates for the common business document types (proposal, contract, report, brief).
The AI agent can read documents, suggest edits (visible as suggestions, not direct writes), draft new sections, and produce a Trust Report appendix that lists every AI contribution to the document with its prompt, its model version, and its checker grade.
AI agents.
The agent layer is what makes the platform “agentic” rather than “AI-augmented”. An agent is a named, role-scoped, audit-logged entity that can read from the platform's knowledge surface and take actions across the other five pillars. Agents are not user accounts. They have their own identity (verifiable via SSO) and operate under per-action consent from the human they're acting on behalf of.
The platform ships with a small set of stock agents — Hunter (research), Sentry (security review), Concierge (calendar/scheduling), Analyst (data summarisation), Pilot (orchestration). Custom agents are configured via YAML, not code, with a permission model that's enforced at the runtime architecture layer. The full agent catalogue is documented in the architecture page.
THE AGENT MODEL
Pilot + Fleet — one orchestrator, four specialists, no shared service account.
The Pilot + Fleet model is how Vantage Workspace structures agent work. Most “agentic” platforms ship one general-purpose agent and let it do everything. The failure mode of that pattern is well-documented: the agent's permission scope ends up being the union of every action it might ever need to take, which means in practice it has god-rights and the audit log is meaningless.
Pilot + Fleet inverts the model. There is one orchestrating agent — the Pilot — that decomposes a user's request into smaller, scoped tasks. The Pilot does not hold permissions. It hands each task to a specialist agent in the Fleet (Hunter, Sentry, Concierge, Analyst), and the specialist holds the narrow permission set required for that task, only for the duration of that task.
This means three things at runtime:
- The audit log is meaningful. Every action is attributed to the specialist that took it, the Pilot that delegated it, and the human user that initiated the request. Three-level attribution, every time.
- The permission scope is minimal. A specialist agent that's been asked to summarise a document doesn't have permission to send email. A specialist that's been asked to schedule a meeting doesn't have permission to read files outside the meeting context.
- The failure mode is contained. If a Sentry agent is compromised (e.g. via prompt injection), the blast radius is the security-review scope only. It can't pivot to send email under the user's identity, because email is the Concierge's permission set, not Sentry's.
The five-agent default catalogue is the starting point. Custom agents can be added — an “Underwriter” agent for an insurance team, an “Examiner” agent for a regulatory review team — using the same YAML configuration. Each new agent declares its permission scope explicitly. The runtime enforces the scope. The audit log records the enforcement.
The full Pilot + Fleet specification, including the YAML schema and the inter-agent communication protocol, is documented on the architecture page.
The runtime
Twenty containers, one SSO, one audit trail.
Vantage Workspace runs as twenty Docker containers, orchestrated by Docker Compose for single-node deployments and Kubernetes for multi-node. The container set covers: the six pillar services (email, files, chat, meetings, documents, agents), the seven defence-architecture services (one per layer), the identity service, the audit service, the policy service, the cost-tracking service, the metrics service, and the trust-reporter service.
Inter-service communication is over mTLS (mutual TLS) only. No service can talk to another service without presenting a verified certificate; the certificate roots are managed by the inter-service auth layer (Layer 6 of the defence architecture). There is no shared service-account credential anywhere in the stack.
Identity is a single SSO source-of-truth — typically the customer's existing OIDC provider (Okta, Auth0, Azure AD, Google Workspace, Keycloak). No local user accounts. No bypass authentication for “service” or “admin” use cases. The audit log records the identity that triggered every action, even when the action was triggered by a Pilot delegating to a specialist agent.
Per-user OAuth credentials (for connectors to external services like Slack, Jira, Salesforce) are stored in a Fernet-encrypted vault with key rotation handled by the platform. There are no OAUTH_CLIENT_SECRET environment variables. There are no API keys in .env files. The vault is the only place secrets exist, and access to the vault is itself audited.
CONTAINERS
20
Docker / Kubernetes
INTER-SERVICE TLS
mTLS
Certificate-rooted
SSO
OIDC
Okta · Azure AD · Google · Keycloak
SECRETS
Fernet vault
Key-rotated, audited
LOGGING
Single trail
Signed timestamps
EXPORT
CEF / LEEF / JSON
SIEM + warehouse
DEPLOYMENT
Ten minutes on infrastructure you already operate.
Vantage Workspace is deployed on infrastructure the customer controls. We do not operate a multi-tenant SaaS. There is no shared production environment where your data sits next to another customer's data. The deployment models are:
The first is single-node Docker Compose — for evaluation, pilot deployments, and small teams. Twenty containers, one Postgres instance, one Redis instance, one Nginx ingress. Deployable on a single 8-core / 32GB VM. The reference install is published as a GitHub Actions workflow that takes a fresh Ubuntu 24.04 server from zero to a running platform in under ten minutes.
The second is multi-node Kubernetes — for production deployments at scale. Helm chart with values for replica counts, persistent volumes, ingress class, certificate manager integration, external Postgres / Redis / object store endpoints. The chart is published in a customer-accessible Helm repository.
The third is air-gapped — for customers operating in classified or no-internet environments. We provide an OCI image bundle (tar.gz of the twenty container images plus signature manifest) and an offline install script. No external runtime dependency on Handvantage infrastructure. License validation is offline (cryptographically signed license file, periodic revocation check via an out-of-band channel).
In all three models, the data plane stays in the customer's environment. The control plane stays in the customer's environment. There is no “phone home” from the running platform to Handvantage's servers. The only Handvantage-operated infrastructure the customer interacts with is the OCI image registry and the documentation site.
EVIDENCE
The evidence is contemporaneous because the platform makes it so.
Every action the platform takes — every email sent, file read, document edited, agent delegation, tool call, identity check, configuration change — produces an audit event. The events are signed with timestamps from a trusted time source (RFC 3161 TSA), sequenced into a tamper-evident log (Merkle-tree-rooted, periodically anchored), and exported in three formats simultaneously: CEF and LEEF for SIEM integration (Splunk, Sentinel, Elastic, Sumo Logic), JSON for data warehousing (Snowflake, BigQuery, Databricks), and human-readable HTML/PDF for compliance documentation.
The HTML/PDF export is the Trust Report. A Trust Report can be generated for any time window, any user, any agent, any document, any tool — or a combination. The report includes:
- The events in scope (with their full metadata)
- The policy that was in effect at the time of each event
- The compliance grade as of the time the report was generated
- A control-mapping appendix showing which events satisfy which control under each of the eleven supported regulatory frameworks
- A signed cryptographic hash of the report itself, anchored against the platform's tamper-evident log
A Trust Report is the artefact a customer hands to an auditor. The auditor verifies the signature against the public verification key. The auditor verifies the events against the events the auditor independently sees in the customer's SIEM (which the platform fed in real time). The two should reconcile to the byte.
This is what “contemporaneous evidence” means in the EU AI Act. It is not a quarterly attestation. It is not a Word document. It is a tamper-evident, third-party-verifiable record of every relevant action the platform took, mapped to the controls the regulator cares about, generated continuously rather than reconstructed retrospectively.
The full evidence specification — event schemas, log signing protocol, Trust Report template — is in the compliance page.
BOUNDARIES
What Vantage Workspace deliberately does not do.
Most product pages list features. This section lists non-features — the things the platform deliberately does not do, why, and what the alternative is.
Vantage Workspace does not host your model.
The platform integrates with your choice of LLM provider — OpenAI, Anthropic, Azure OpenAI, AWS Bedrock, Google Vertex, or self-hosted (Ollama, vLLM, TGI). We do not ship a “Handvantage AI model”. The point of the platform is the architecture around the model, not the model itself. If your AI strategy requires a specific model (Claude for legal review, GPT-4 for code, a fine-tuned in-house model for customer support), the platform routes prompts to the right model based on policy, with the routing decision logged.
Vantage Workspace does not analyse your data outside your environment.
There is no Handvantage analytics endpoint that the running platform calls home to. The cost-tracking, the usage metrics, the agent activity logs — all of it stays in the customer's environment. We do not have a data lake of customer activity. We never will.
Vantage Workspace does not “auto-improve” from your data.
The platform does not fine-tune any model on your data. The platform does not ship “feature improvements” that were trained on observed usage from any customer. Model behaviour is deterministic against the model version pinned in your deployment; upgrading the model version is an explicit operator action with a published changelog.
Vantage Workspace does not include identity, secrets management, or directory services.
The platform integrates with whatever you already operate (Okta, Auth0, Azure AD, Google Workspace, Keycloak, HashiCorp Vault, AWS Secrets Manager). The platform does not try to replace those layers. The decision rationale is documented on the architecture page: identity is too important to re-implement.
Vantage Workspace does not “auto-classify” or “auto-redact” content.
There are policy hooks where a customer can configure classification or redaction (e.g. via a connector to Microsoft Purview, AWS Macie, Google DLP, or a custom classifier). The platform does not ship its own classifier. The reason is operational: classifier behaviour drifts over time, and the customer's compliance team needs control over the classifier's training and update cadence.
ENGINEERING CADENCE
Sixty-eight sprints. Zero rollbacks.
The release cadence is two-week sprints. Sixty-eight sprints have shipped since the v0.1 release. None have been rolled back to production after deployment. The discipline that produces this number is:
- Every sprint ships a release candidate to a pre-production deployment that mirrors a real customer environment. The release candidate runs for the full two-week sprint. Defects identified in the release candidate go into the next sprint's plan; the candidate doesn't ship until the defect rate is zero.
- Every release candidate runs the full automated test suite. 168 tests. The test suite covers the seven defence layers, the OWASP Top 10 categories, the identity flows, the audit log integrity, and a fuzzed prompt-injection corpus. The suite runs in CI on every commit and on every release candidate.
- Every release candidate is graded by the same
/assessmission that grades the production deployment. If the release candidate's compliance grade is lower than production's, the release does not ship. If the test suite degrades, the release does not ship. If a release ships and a regression is identified within 72 hours, it triggers a forensic post-mortem and a hot-fix sprint. - The platform supports rollback in under ten minutes. Container images are immutable, OCI-signed, retained for the lifetime of the deployment. Rolling back is a single Helm or Compose command. We have not used the rollback path in production. We rehearse it monthly.
The 68-sprint, zero-rollback record is not a marketing claim, it's the operational discipline that lets the platform earn the audit signature it claims. The sprint history, the test growth curve, and the assessment grade timeline are published in the insights archive.
CONTINUE THE CONVERSATION
If you'd like to walk through a deployment, talk to us.
The most useful conversation about Vantage Workspace is the one where we sit with your operator team for thirty minutes and look at your existing identity, audit, and compliance posture. We'll tell you where the platform fits and where it doesn't.
Talk to us about a deployment →Or write to hello@handvantage.com directly.