TabTin: An AGPL-3.0 Workspace Where Humans and Multiple Agents Share One Task
A workspace where people and multiple AI agents work together.
At a glance
- What is it?
- TabTin is a TypeScript, AGPL-3.0 licensed collaboration platform that puts agents and people on the same documents, tables and presentations, with a Community Server meant to run on your own machine. It is in Public Preview, and the README is unusually explicit about which parts are not finished.
- Who is it for?
- Adopt TabTin if you are already running agents per person and losing the reasoning behind the output: the handover model, which freezes conversation context and carries shared documents into the next task, targets exactly that loss. Do not adopt it if you need a finished cross-platform product, since the README states the mobile clients are control surfaces that require a desktop execution environment to be online, and that Project is deferred to a later version.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 16 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem TabTin picks: finished work that nobody can pick up
The README frames the product around a narrow question: can work one person has already completed become the starting point for the next colleague? The claim behind it is that AI raised individual output without raising team throughput, and that the gap shows up as repeated research, lost context and judgement, wasted tokens, methods that cannot be reused, and unclear ownership of results. That is a specific diagnosis, not a general pitch about productivity.
The intended audience is stated twice. Deep AI users are the first segment, but the README explicitly says they are not the product boundary, and extends the target to any individual or team that wants agents inside real work. Users configure agents, models, skills and execution rules, then let agents take part in research, data collection, documents, spreadsheets, presentations and code. Teams add handover, permission, model, usage and execution records on top.
One design decision is worth flagging early because it shapes everything else: the README states that agents can execute work, but that important judgement, responsibility confirmation and result acceptance remain with people. TabTin is not trying to remove the human from the loop. It is trying to make the human's part legible to the next person.
Handover freezes context, not just the final document
The handover mechanism is the most concrete thing in the README. When a task is continued, the system freezes the necessary conversation context and carries along documents, spreadsheets, cloud files and local files that were referenced in the task and that the user has the right to share. The person taking over can see how a conclusion was formed and then create an independent task in their own chosen agent and workspace.
Two constraints sit inside that description. The first is a permission filter: only referenced files the sharer is entitled to share travel with the task, which means a handover can arrive with gaps and the receiving side has no way to tell from the handover alone what was withheld. The second is that local files and execution environments stay independent per person. The README says completed research does not need to be redone, but it does not claim the receiving machine can reproduce the sender's runtime. That is a deliberate boundary, and it is also the point where a handover can look complete while being un-runnable.
Beyond handover, TabTin ships collaboration applications for messages, documents, multi-dimensional tables and presentations, and agents can create and edit that content directly. Data and media collected in a browser can flow into those same work applications. The design intent is that a person and an agent look at one online result rather than passing files between a chat box, a download folder and an office suite.
Reusable methods live in agent configuration, not in someone's prompt history
TabTin's answer to method reuse is configuration rather than documentation. Different agent roles can carry their own rules, models, skills and memory, and the README names research methods, review rules, test steps and release processes as things that can be reused in later tasks instead of depending on a prompt a team member wrote once and pasted around.
The upside is that a verified method becomes a durable object rather than folklore. The cost is that the method now has an owner and a maintenance path, and the README does not describe versioning, review or deprecation for agent configurations. It also does not describe what happens when a shared method references a model that a receiving team cannot access. Those are the questions to ask before treating a configured agent role as institutional knowledge.
The README is careful about scope here: it says only capabilities that already exist in the public code and have been verified are written up as current, and that future direction belongs in ROADMAP.md. That is a reasonable editorial rule, and it also means the README is not a feature list you can plan against.
Running the Community Server: two preview modes and one .env file
There are two entry points. The official service at tabtin.com is for people who do not want to maintain a server. Running the source locally is for people who want to debug or extend TabTin, and the README is explicit that both local paths are development entry points, not a Community distribution package or an official release build.
The manual path starts in the repository root. Copy the template once, which does not overwrite existing local files:
cp .env.example .env
Then pick a preview. Quick preview starts the Community backend, Collab, Centrifugo and Electron:
node scripts/dev.mjs community
Full preview starts the backend, AdminDash, tabtin-web and Electron, waiting for the backend health check before launching the rest:
pnpm dev
On Windows, start-community-dev.bat; on macOS, start-community-dev.command. The README states both are equivalent to quick preview and will not start AdminDash or tabtin-web, and that Linux users should use the command line. Individual services can be started with node scripts/dev.mjs backend, admindash, tabtin-web or electron, but the README notes these do not replace the health check and startup order of a full preview.
Configuration is deliberately small. The Community entry point reads only TABTIN_EDITION and AUTH_FIXED_VERIFICATION_CODE from the root .env, and generates an internal runtime file without other secrets. The template defaults TABTIN_EDITION=community. Leaving the fixed phone verification code blank disables it and switches to the real sending path. Personal overrides go in .env.local, and the README states neither file may be committed. For mainland China networks there is node scripts/dev.mjs community --region cn. If you prefer an agent to do the setup, the README points at docs/development/community-dev-agent-prompt.md and gives literal instructions such as asking it to run the quick preview; the agent is required to pause for user confirmation on system permissions, first Docker startup, security prompts and licence confirmations, and may only report success when the backend is healthy and the Electron window is ready.
Where TabTin is the wrong tool today
The README's own status section is the strongest limitation. TabTin is in Public Preview and undergoing its first full public release. Core workflows are usable, but component maturity and cross-platform experience still differ, some modules use default implementations with replacement and extension still incomplete, and the Community Server is mainly intended to run on a local machine. Project is named as the capability the next version will focus on, which means it is not the thing to build a process around now.
Mobile is the sharper constraint. The README states the mobile clients are companion entry points to the desktop client and do not provide an independent agent execution environment. To start or control an agent task from mobile, you must first configure the execution environment and bind the device on desktop, and that computer must stay online while the task runs. Installing only the mobile app cannot execute agent tasks. Android and iOS debug packages are built separately on their respective platforms and are not started by full preview.
There is also a data boundary worth reading carefully. The README says the Community Server listens only on the local address by default and stores accounts, configuration and business data in local Docker volumes, and that the Community client does not connect to the maintainer's Sentry error monitoring or update service by default, with full diagnostic packages uploaded only after explicit user consent. That is a sensible default, but it also means a local Community deployment is a single-machine setup, and the README does not describe backup, migration or multi-user hosting for it. If you need a shared server for a distributed team, the documented paths are the official service or a commercial arrangement.
How TabTin differs from running one agent per person
The realistic alternative is not another agent framework. It is what most teams already do: each person runs their own agent in their own client, and collaboration happens by pasting results into chat or exporting files. That approach has real advantages. There is no server to run, no shared permission model to design, and no risk that a handover carries context you did not intend to share.
The difference in approach is where state lives. In the per-person setup, the conversation and the reasoning behind a result stay on one machine, and the artifact is the only thing that crosses the boundary. TabTin moves the task, the frozen context and the referenced files into a shared online object, and puts messages, documents, tables and presentations in the same place so an agent can edit what a person is editing. The trade is straightforward: you gain continuity and auditability, and you take on a server, a permission model and a synchronisation layer. For a solo user, that trade is usually bad. For a team where two people research the same question in the same week, it is the whole point.
The README also positions the repository as product code rather than a simplified demo, and lists the intended public scope as desktop and mobile clients, server, agent runtime, real-time collaboration, messages, documents, tables, presentations, model management and an admin console. It adds that the final scope and availability during Public Preview follow the release snapshot and verification records, which is an honest way of saying the list is a plan, not a guarantee.
Licence, maintenance and what the repository does not tell you
The public source is AGPL-3.0-only. For uses or distribution scenarios that cannot adopt AGPL-3.0-only, the README directs enquiries about a separate commercial licence to contact@larchiveai.com, addressed to Shanghai Mofan Technology Co., Ltd. Third-party components keep their own licences, listed in THIRD_PARTY_NOTICES.md. The TabTin name and logo are trademarks of the maintainer, and fork projects may state truthfully that they are based on TabTin but may not present themselves as the official version. If you plan to host a modified TabTin for other people, the network-copyleft terms of AGPL-3.0-only are the part to read with your own counsel before you build a service on it.
On maintenance, the repository is not archived, and the last push was on 2026-08-31, with v1.1.3 released the same day and v1.1.2 on 2026-08-22. That is a recent cadence, but the README's own Public Preview framing is the better signal for planning: it states that some modules are default implementations, that extension points are incomplete, and that Project is deferred. Upgrade cost is not documented in the README. There is no rollback procedure, no migration guide between releases and no compatibility statement for the local Docker volumes that hold Community Server data. The CHANGELOG.md is listed in the documentation index, so that is where to look before pulling a new version, and the Docker volume behaviour is the thing to verify on your own machine first.
Editorial conclusion
Adopt TabTin if you are already running agents per person and losing the reasoning behind the output: the handover model, which freezes conversation context and carries shared documents into the next task, targets exactly that loss. Do not adopt it if you need a finished cross-platform product, since the README states the mobile clients are control surfaces that require a desktop execution environment to be online, and that Project is deferred to a later version. Before committing, run node scripts/dev.mjs community on a machine with Docker and confirm the backend health check and Electron window both come up, then read the AGPL-3.0-only terms against your distribution plans and check whether Shanghai Mofan Technology's separate commercial licence is the path you need.
Community notes