CodeKasten is a platform for building the tools a team works in. You describe what you keep track of — projects, tickets, customers — as record types, and the platform gives each one a list, a form, a detail page, filters, saved views, commands, a GraphQL API and tools for agents. The interface is drawn from the definitions every time rather than generated once and left to maintain. CodeKasten documentation
We are writing about CodeKasten because of how it answers a question we have been working on for months: when an AI agent works on a real system, how far should its write access go, and who decides what is kept.
The founding idea: everything is a record
A project is a record. The definition of the Project type is a record too. So is each of its fields, a view, a workflow, an item in the sidebar.
That is the structural trick that makes everything else work. Because they are all the same kind of thing, they can all be branched, committed, merged, translated and shipped in a package. Define a record type and it immediately has lists, forms, filters, a page of its own, an API and tools for agents — with no schema to migrate.
Workspaces branch like a repository
A workspace has branches like a code repository. You change things on a branch, commit, and merge. main is protected by default, so a team can require that changes are looked at first.
The way of working the documentation recommends is the one a careful colleague would follow: make a branch for the agent and a key on it, let the agent work and commit, have the agent call request_merge to ask the people who may merge, then a person reads the commits and decides. One small but well-judged detail: when a tool refuses something, the refusal comes back as that tool's result, worded for the model, so the agent understands why and can try another way. Agents (MCP) documentation
The agent inherits the user's identity and rights
This is where CodeKasten makes a notable choice. An agent uses an API key, so it is the person who created that key: on that key's branch, with that person's role in the workspace. A reader's agent reads and no more. A key for a branch its person can no longer read simply stops working.
Set beside OpenAI's specialist dots, these are two opposite answers to the same question. OpenAI gives each agent its own identity and credentials, making it a new principal in the access model — and therefore something that needs governance tooling of its own. CodeKasten creates no new principal at all.
This makes revoking access simple: cut the person's access and the agent stops with them, with no machine accounts left open to remember. Traceability runs the other way and can get harder: in the log, an agent's action looks like an action by whoever holds the key. To tell who or what changed a record you have to add a layer of your own. In a tightly regulated industry that may be a condition you cannot skip.
Approve before, or undo after?
While looking into CodeKasten we also took note of Claude Duet, a product Anthropic has introduced as a research preview. Duet is a proactive AI assistant that runs on its own cloud computer, gathers what needs the user's attention, takes requests by message and does the work through connectors already set up.
Unlike OpenAI Dots, which gives each agent an identity of its own, Duet uses the user's Claude account, along with its memory, skills and established connections.
The more notable difference, though, is in how the agent's actions are controlled. With Duet, sensitive operations such as sending a message or making a payment require approval before they execute. CodeKasten comes at it from another direction: the agent may make changes on a branch of its own, record them as commits and then request a merge, and those changes are reviewed before they become the system's official state.
Put CodeKasten, OpenAI Dots and Claude Duet side by side and two control principles appear, not three.
Control before execution suits actions that create effects outside the system: sending email, moving money, approving a transaction, driving equipment. Once the action has happened, undoing it may be very hard or impossible.
Isolating changes and reviewing them before the merge suits changes of data state that can be kept, compared and examined before they reach the official environment.
The two mechanisms do not exclude each other. They complement each other, and agentic systems with real safety and governance requirements need both. An agent may autonomously make a long series of changes in its own workspace, but before those changes are merged or trigger irreversible effects, the system needs the appropriate control points.
From which follows an architectural principle: not every agent action needs human approval, but every action carrying significant risk must sit inside a control mechanism that can be identified and verified.
The scope of these products should also be distinguished. Claude Duet aims at being a proactive personal assistant, while CodeKasten is a platform for building applications and managing data by version. The comparison here is therefore about the philosophy of controlling agents, not a feature-by-feature comparison. Duet is currently a research preview: a waitlist, Pro and Max plans in the US, with Team and Enterprise not included yet; Anthropic states that Duet may misread a thread, miscalibrate what is urgent, and miss something that arrives between check-ins.
Apps are packages, workflows are data
Record types are built in an app workspace and published as a release. A release never changes once published, so ten teams can install the same Helpdesk app and each keep their own tickets; an upgrade is a new release, taken when each team is ready. Apps and packages
Workflows are data too: drawn on a canvas, compiled into a plan and run by the workflow engine when the trigger fires. The notable part is that they run on Temporal, so a step that waits a week survives a restart. Workflows
What is genuinely new in CodeKasten
- Version control pushed down to the data and the definitions, not just the code. That is the hard part, and the reason the “everything is a record” trick exists.
- An agent's data changes are isolated on a branch of their own and can be discarded before they are merged.
- The agent does not create a new principal to govern — the opposite of where most agent platforms are heading.
- Immutable releases let the same toolset reach many teams without tying them to one upgrade schedule.
There is one point we want to make separately, because it is not a limitation of CodeKasten alone but of the branch model itself. Merging data is not the same as merging code. Reverting a code commit is the repository's business. But an email already sent, money already paid, a setpoint already pushed to a machine cannot be put back by a revert button. The branch model protects state inside the box very well; it does not protect effects that have already happened outside it.
Put differently: a branch is an excellent fence around data, and only half a fence around workflows with side effects. Which is exactly where we keep saying that control policy has to be independent of the agent and enforced in the business or integration layer rather than inside the tooling the agent runs in. Whatever reaches into the real world needs a stopping point of its own.
The opportunity, seen from Vietnam
When an agent is allowed to write into a real system, the first design question is always: where is its branch, and who merges? Most companies answer it by building the buffer themselves — a draft state, an approval queue, a separate environment — and then writing the diff layer, the approval layer and the audit layer around it. That is months of work before an agent produces any value at all.
What makes CodeKasten worth trying is that it hands you that part. Branches, commits, merges, a protected main, a history that carries the reason for each change, merge requests landing in the right person's Inbox — all there from day one, and for data rather than code alone. Define a record type and you immediately have lists, forms, filters, a GraphQL API and tools for agents, then package it as an app and install it anywhere.
For companies in Vietnam we see three groups it fits best: teams that want internal tools quickly without opening a full software project; teams already using Claude Code or another MCP client that need somewhere safe for an agent to work; and teams that have to ship the same toolset to several member units, each on its own upgrade schedule.
The cheapest way to find out is to read the documentation, see how they picture people and agents working together, then open the app and connect Claude Code through the MCP server. An afternoon is enough to tell whether the model suits the way your team works.
That is the direction we took with MaiStudio, Mobino's own internal tool for Mendix development: each agent works in its own workspace and git branch, and a reviewer reads a model-level diff before anything enters the project. An independent product arriving at the same conclusion from an entirely different direction is a signal worth noting about the pattern itself.
Reduced to one sentence worth carrying: an agent may be autonomous in how it executes, but it may not decide on its own to cross a control boundary. That boundary is set by people, sits beyond the agent's reach, and has to be verifiable after the fact.
If your team is designing flows like these, see our automation and AI page.
Sources: What is CodeKasten · Agents (MCP) · How your team and AI agents work together