Your AI agents, on servers you control. Set up by the team that builds them.
Run a team of AI agents on your own servers, using the AI vendors you already contract with, without moving your work into another vendor's suite. Start with one workflow, on one server, for 60 days.
- Runs on your Linux servers, or a dedicated K2 Cloud server
- Any model vendor, on your contracts
- Source your security team can read
| Agent | Model | Database | |
|---|---|---|---|
| intake | Claude | approval | off |
| scheduler | Gemini | off | granted |
| reporting | Codex | off | off |
| review | local model | off | off |
Example server. Mail, database, DNS and app powers are off until an Owner or Admin grants them.
Agents are arriving faster than anyone can govern them.
Okta's 2026 report found 91% of companies already use AI agents, and only 10% have a well-developed plan to manage them. The governance on offer usually comes inside one vendor's cloud and suite. K2 takes a different route: the agents, their files and their permissions live on servers you run, and each agent can use whichever model vendor you choose.
Source: Okta, Businesses at Work 2026.
A team of named agents, on infrastructure you own.
Runs on your infrastructure
A Linux server in your environment or, if you'd rather we host it, a dedicated K2 Cloud server (then we're your hosting provider). The agents' files, database and mail live on that box. For isolated networks, a version that makes no outbound connections to us is available by agreement; fully offline also needs local models.
Any model vendor
Claude, Codex, Gemini, Grok, GitHub Copilot, local models and more, a different one per agent, on your own contracts. K2 never marks up model usage. Prompts go to the vendor you choose, or stay local with local models.
Every agent is named
Each agent has its own identity in K2, plus its own workspace and address (not a separate OS user). The K2 daemon refuses owner actions and K2's locked tools to agents unless granted, and records sign-ins, mail sends, schedule changes and agent-to-agent messages.
People and partners, scoped
Owner, Admin and Member logins. Staff, clients and partners get an app that shows only what you grant, never a terminal. Each business unit can run its own server and still let its agents message the others.
Readable and portable
The source is visible under Fair Source and free for internal business use. Each release becomes Apache 2.0 after two years. With remote access off, your server runs on your own network. For isolated networks, a version that makes no outbound connections to us is available by agreement.
Delivered by the builders
The team behind K2 scopes the pilot with you, sets up the server and the agents, and stays on for support. You talk to the people who write the software.
One workflow. One server. Sixty days.
Start contained, measure it against what you run today, and decide on day 60.
- Weeks 0 to 2Scope and build. We pick one workflow or one rented ops app with a named owner in your business. The agents run on a VM or server in your environment, or a dedicated K2 Cloud server, on non-production data or read-only connections, with your own model keys.
- Weeks 3 to 8+Run side by side. Agents hand work to people through tickets, a review queue and mail approval, and connect to your systems read-only first, through the APIs those systems offer. Where your security team wants it, agents ask a person before running any tool, except K2's own messaging commands, so the team can still talk. You loosen the rules as you see the work.
- Day 60Go or no-go after about two months side by side, against metrics agreed up front: license cost you could retire at renewal, hours saved a week, cycle time, weekly users, rework rate and monthly model cost from K2's own token charts.
- Intake reads new service requests from a shared inbox and drafts a work order for each.
- Scheduler checks crews and parts in a read-only copy of your data and proposes a slot.
- Reporting writes the morning summary for the branch manager: what's booked, what's stuck, what needs a person.
- A dispatcher approves each booking before anything reaches a customer.
A nearly ten-year-old Quickbase system, replaced without stopping work.
The team behind K2 rebuilt a field-services company's operations system as software the company owns, with agents built in. Staff kept working throughout, and the move took about a month and a half.
This is a small company, shown here as proof of how we deliver, not of enterprise scale.
About $55,000 a year on Quickbase before, about $18,000 now: roughly $37,000 saved each year. Figures are the client's own, shared with their permission.
At launch, 80 staff filed 350 tickets and the agents resolved every one within three days. Read the case study · Launch week
A small team. You talk to the people who write it.
K2 is built by Alakazam Labs, a small, founder-led team that runs its own companies on K2 agents. The same team scopes your pilot, sets up the server and supports it.
What that means for your vendor review: the source is public under Fair Source, the software runs on your server whether or not we're around, and roadmap gaps are listed in the table below instead of being discovered later.
Alongside your suite, not instead of it.
Microsoft (Copilot Studio), Google (Gemini Enterprise), Salesforce (Agentforce), ServiceNow, OpenAI and Anthropic each offer ways to build and govern agents inside their own cloud and suite. K2 runs a team on your server with any of their models, and can sit alongside them. If you've standardized on Copilot for office work, keep it there; K2 is for the workflows you'd rather run on your own server, like the rented ops app that just got more expensive.
Your stack
Agents reach Microsoft 365, Google Workspace and your line-of-business systems through the APIs those systems offer, read-only first. Plus a CLI for everything, a /v1 HTTP API that's off until you enable it, MCP through your agent CLIs, and agent-to-agent messaging between your servers over your network, or across sites with K2 Connect.
Your models
Use the model vendors you already contract with. Each agent can use a different one, and you can switch without rebuilding the team.
Open alternatives
OpenClaw Enterprise is a free, self-hosted option built with Red Hat and NVIDIA. K2's difference is the bundle: named agent teams, apps for staff and partners, mail and a database on the box, and setup by the team that builds it.
K2 doesn't support the A2A protocol today; agents on different K2 servers talk through K2's own messaging.
What's ready, what's planned, what isn't.
Version 0.45, checked October 8, 2026. "Planned" means on the roadmap with no date. "Longer term" means not planned soon. We'd rather you read this here than find it in review.
| Area | Ready today | Planned | Longer term or not planned |
|---|---|---|---|
| Where it runs | Your Linux server (x86_64 or aarch64, headless, signed installer) or a dedicated K2 Cloud server. A Mac app exists for desktop use. | Windows desktop app | |
| Network | Remote access, the phone app and cross-company messages go through K2's relay in Ashburn, Virginia (US), end-to-end encrypted. Servers can also pair directly on your network. For isolated networks, a version that makes no outbound connections to us is available by agreement, and we'll list every outbound connection for your review. | Relays in other regions | |
| Data | Agents' files, database and mail stay on your server. Prompts go to the AI vendor you choose, or stay local with local models. | ||
| Human sign-in | Username and password, lockout, and a sign-in audit for Owners. Until there's SSO, keep the server on your network or VPN so your own identity controls sit in front of it. | SSO, MFA and SCIM: not scheduled | |
| Roles | Owner, Admin, Member, enforced on every route. Agent permission switches need Admin or Owner. | Finer admin roles | |
| Guest access | Apps for staff, clients and partners, limited to the agents and functions you grant. No terminal. | ||
| Agent identity | Per-session identity, revocable at once. Owner actions refused to agents. DNS, mail, apps and database off until granted. K2 sends agent email through its own mail helper and never hands a mail password to an agent without mail permission. Mail can require approval before sending. | Safer defaults for agent tool permissions | Separation between agents: the K2 daemon and all agents on one server run as one OS user, so an agent can reach the other agents' files and the server's stored keys. Run one business unit per server. |
| Approvals | Tickets with a written brief, a review queue and a mail approval queue. Built-in presets skip the CLI's own tool prompts; you can keep them on and allowlist K2's own commands so agents still message each other. | Safer defaults | |
| Audit | Sign-ins, mail sends, schedule changes (who and when), agent-to-agent messages | Full log of agent commands and file edits; SIEM export | |
| Model credentials | Extra AI logins and API keys are kept in one owner-only file on the server, outside agent workspaces, and no K2 route returns them. Agents run as the same OS user, so this keeps keys out of reach of K2's interfaces, not out of reach of an agent's shell. | ||
| Sandboxing | None in the standard build. Use a VM per server for isolation. | microVM sandbox (a build option, not in the public release) | |
| Cost | Token ledger and subscription meters by agent and model | Spend caps: not planned | |
| Interop | CLI, /v1 HTTP API (off until enabled), agent messaging between K2 servers, MCP through your agent CLIs | A2A (not planned) | |
| License | Fair Source FSL-1.1-Apache-2.0: source visible, free for internal business use, Apache 2.0 after two years | ||
| Compliance | No certifications held | SLA and support terms | SOC 2, ISO 27001 |
The software is free. You pay for the server and the help.
K2 software: free for internal business use under Fair Source (the one thing it doesn't allow is offering K2 as a competing hosted service). Your security team can read the source of the public release.
The server: yours, or a dedicated K2 Cloud server we run for you.
Remote access: optional. K2 Connect gives a server its own address for remote staff, the phone app and links between sites.
Models: your own contracts with the AI vendors, at their prices. No markup.
The pilot and setup: a fixed fee agreed before we start, scoped on the first call.
What security and IT teams ask.
Where does our data go?
The agents' files, database and mail stay on your server. Prompts go to the AI vendor you choose for each agent, under your contract with them, or stay on the box if you use local models. If you turn on remote access, traffic for the phone app and remote staff goes through K2's relay in Ashburn, Virginia, end-to-end encrypted.
Who can reach the server?
The people you add, as Owner, Admin or Member, plus guests on the apps you publish, who never get a terminal. Remote access is optional: you can keep the server on your own network. For isolated networks, a version that makes no outbound connections to us is available by agreement.
What can an agent do on the box?
Each agent can do what its CLI can do as the server's user: read and change files, run commands and use the web. K2 adds an identity per agent, refuses owner actions from agents and keeps K2's own mail, DNS, app and database powers off until granted. It doesn't separate agents from each other at the OS level, so run one business unit per server and use non-production data in the pilot.
Does the pilot move our data off the current app?
Not by default. The pilot runs on a read-only copy or export of the data, next to the app you use today, so nothing changes for your team while you measure it. Moving off the old app fully is a separate step after a go decision, the way the case study above was done.
Do you have SOC 2 or SSO?
Not today. SSO, MFA and SCIM aren't scheduled, and we don't hold SOC 2 or ISO 27001. The pilot is shaped around that: your server, your network, non-production data, and the review table above filled in for your environment.
Can we see the source?
Yes. K2 is Fair Source (FSL-1.1-Apache-2.0): the source is public, free for internal business use, and each release becomes Apache 2.0 after two years.
What happens if you go away?
The software runs on your server and keeps running, and you have the source; each release becomes Apache 2.0 after two years. K2 Connect remote access and phone push depend on our services, so plan your own network access for anything critical.
Which models can we use?
The agent CLIs from Anthropic, OpenAI, Google, xAI, GitHub and others, plus local models. Each agent can use a different one, on your own API keys or contracts. K2 never marks up model usage.
Does it work with MCP?
Yes, through the agent CLIs. K2 runs Claude Code, Codex, Gemini and the rest unmodified, so the MCP servers you configure for them load as usual.
Start with one workflow on one server.
A call with the team that builds K2. You come away with a pilot scope, the success metrics and the security table filled in for your environment.