Open Customer Service Orchestration
Built with Winsen Labs
OCSO is open source, and you can run it yourself. If you would rather rethink customer service with the people who build it, Winsen Labs works alongside a small number of teams at a time. We select those engagements carefully, so each one gets our full attention.
01
Map how you serve customers today
Your channels, queues, teams, tools and the edge cases that fall between them.
02
Stand up OCSO on your infrastructure
Your servers or your cloud account, your model providers, your systems connected over MCP.
03
Run it with your team
Agents, routing and hand-offs shaped with the people who serve your customers, every change approved.
Tell us about your customer service team, and we’ll set up a walkthrough.
Request a demoAbout Winsen LabsThe problem
Every channel, tool and team handles its own slice of the customer, and nobody sees the whole. AI bolted onto the edges only adds another silo. Customer service needs rethinking for the AI age: one layer that orchestrates every channel, agent and person.
Scattered, today
Orchestrated, with OCSO
Channels
TodayA bot on the website, a WhatsApp number run by a vendor, Slack for your biggest accounts. Each with its own rules and its own history.
With OCSOWhatsApp, web chat, Slack and Microsoft Teams behind one contract: one conversation model, one hand-off, one audit trail.
Tools
TodayA helpdesk, a bot builder, a CRM and a spreadsheet of who handles what, stitched together by people.
With OCSOOne path for every customer: channel, router, queue, agent. Your own systems join as tools over MCP.
Teams
TodayThe bot belongs to one team and the queue to another. At the hand-off, the customer explains everything again.
With OCSOAI agents and people on the same conversation, with explicit control states and the AI summary carried across.
Edge cases
TodayThe case nobody configured falls through the cracks, and nobody notices until the customer complains.
With OCSOEscalation rules, SLA policies and a weekly signed report of the customers routing could not place.
AI
TodayBolted on in places. Prompts edited in production, with no record of who changed what, or why.
With OCSOVersioned prompts, and every change to live configuration approved by a second person and written to a signed audit store.
The OCSO way
Every customer takes the same readable path, whichever channel they write on. AI agents and your people work the same conversations, and hand them to each other in both directions.
01 · Channels
Each message is verified and stored before anything else happens.
02 · Routers
Ask a menu question, classify with a model, or use what you already know, then pick a queue.
03 · Queues
The service unit: one AI agent, its human teams, an SLA policy, hours and transfer targets.
04 · Agents and people
The AI answers with the tools you approved. A rule, the customer or the agent can bring in a person.
Hand-off both ways. Every change of control is explicit and audited:
Four role presets, checked in code, with per-user grants on top. Each team sees what it owns.
Claim the next customer from the pickup queue, with the SLA clock and the AI’s summary in front of you.
Queues, teams, skills, languages and SLAs: every change goes to a second Head for approval.
Workers, latency, tokens, providers and incidents, without reading conversation content.
Every privileged action attributed to a person, backed by a hash-chained, signed store.
Screens from OCSO running with demo data.
Head
For customer service leaders
Full authority inside your teams: agents, queues, SLAs and quality. You check your colleagues’ changes and sign the exception report.
Lead
For team leads
Run your teams’ agents, prompts, queues and routers. Propose changes, replay a draft prompt on past conversations, and roll back.
Service
For service teams
Handle the conversations in your queues. Take over from the AI with the context in front of you, then hand back.
Tech
For platform teams
Run the platform: model providers, channels, MCP, sign-in and audit verification, without reading conversation content.
Ask OCSO · ⌘J
Its tools are generated from OCSO’s own API and filtered to your permissions, so it grows with the product.
It acts as you, never as more
Every call goes through the real API with a single-use delegation for you: the same permissions, team scope, approvals and audit as the app.
Every write is a card you confirm
Reads answer straight away. A write comes back as a confirmation card built by the server, and runs only when you click.
Governed changes go to a checker
A change that needs approval becomes a proposal, and the checker can review and decide it from Ask OCSO too.
Also in Slack and Microsoft Teams
Link your chat account once and ask as yourself, with the same cards, approvals and audit.
Governed by default
Maker–checker approvals, a separate signed audit store and a weekly exception report.
Read more →
Built to extend
Channels, models and alerts are plugins. Your systems connect as MCP tools.
Read more →
Yours to host
Apache-2.0. Docker Compose on your own server, or Terraform for AWS.
Read more →
Governed for real
Built for regulated service teams. Permissions are checked in code, never in a prompt, and nothing a model says can grant one.
Approvals: the checker sees the maker, the reason, the content hash and exactly what would change.
01
Maker–checker on every configuration change
Agents, prompts, tool grants, routers, queues, SLA policies, channels, providers, MCP connections, SSO, users and permission grants. Each change is a proposal a named second person approves, and the checker approves exactly the content they saw, enforced by content hashes. Stops such as pause, disable and revoke apply at once.
02
A separate, signed audit store
Audit events commit in the same transaction as the change, then ship to their own append-only database (PostgreSQL or ClickHouse) that the application cannot rewrite. There they are hash-chained, checkpointed with Ed25519 signatures, exported daily and verifiable offline.
03
A weekly signed exception report
Where the controls were bypassed or failed: configuration live without an approval, self-approvals, rights granted around approval, customers routing could not place, audit events that did not reach the store, a chain that did not verify.
Roles, and verification you can run yourself
Four presets (Tech, Head, Lead, Service), per-user grants with an optional expiry, and team-scoped ownership of agents. Taking access away applies at once; widening it needs approval. The audit-verify tool re-checks the hash chain against the signed checkpoints, trusting only the public keys you pin.
Security and governance, in detail →$ docker compose run --rm migrate \
node audit-store/dist/bin/audit-verify.jsOpen source
OCSO is a core plus contracts. Everything that touches an outside system is a plugin, and a lint rule fails the build if core code names one. Six model providers ship today: AWS Bedrock, Google Vertex AI, Microsoft Foundry, OpenAI, Anthropic and Sarvam.
Plugin SDK
@winsendotai/ocso-plugin-sdkComing to npm
The public contracts for channels, model providers, alert destinations and email drivers, plus a conformance kit. OCSO refuses to start on a version mismatch.
Read the guide →
Chat SDK
@winsendotai/ocso-chatComing to npm
A headless client for browsers and React Native, with React hooks and themeable components on top, to build your own chat on OCSO.
Read the guide →
MCP tools
Added in the app, no code
Connect any MCP server over Streamable HTTP with OAuth 2.1. Classify each tool’s risk, approve it per agent, and require a person to confirm sensitive actions.
Read the guide →
Docker Compose, on your own server
The supported deployment: one host with four vCPU and 8 GB of RAM for a pilot, and a Caddy overlay for HTTPS. Single-tenant: one deployment belongs to one organization.
git clone https://github.com/winsenlabs/ocso.git && cd ocso
cp .env.example .env
docker compose up -d --buildAWS
Terraform for ECS Fargate with S3, SQS and Secrets Manager drivers. Validated, not yet applied to a real account: a starting point.
AWS guide →Hardened by default
Non-root, read-only containers; the database on a network with no internet access; credentials envelope-encrypted and kept out of logs, prompts and audit payloads.
Apache-2.0. OCSO is pre-1.0: APIs, the schema and plugin contracts can still change.
Request a demo
Tell us who you are and how your team serves customers. We’ll reply to set up a walkthrough shaped around your channels and volumes.
What happens next