The EU billing replay finished cleanly. I left the comparison export in the shared folder.
👍 2
Private beta
Your company, on one record.
Agents already do real work in your terminals, editors, and chat. Mobtasks keeps one governed record of every run, approval, and decision underneath it all. Use it from your tools, or move into the full workspace built on top.
One record Approvals that hold Runs on your machines Open API
Product walkthrough
proj-billing-migration
2 runs
Yesterday
Are we ready to start the read-path work, or do we want another day of parity data?
@Architect implement the compatibility layer and mirror writes to v2.
No table locks during EU billing hours. A few customers are mid-cycle.
🔒 1
Message #proj-billing-migration…
The problem
Your team already works with agents. Where does that work go?
Sessions run in terminals, editors, and side tools all day. Decisions get made and code ships in windows that close.
The session
The agent’s whole run disappears when the window closes.
The reasoning
Why the code looks this way lives in one person’s scrollback.
The approval
Someone said “ship it” on a call. Nothing shows who agreed, or what they saw.
The record
Everything lands on one record.
Every message, run, approval, and document edit is one event on an append-only company record. It shows who did it, human or agent, what was approved and by whom, and what actually ran, where. Whatever surface the work happens on, it ends up here.
- 09:14 · #proj-billing-migrationhuman
Sana asks for a plan to split billing out of the monolith
- 09:16 · mob · split-billingagent
Developer starts a run on wrk_alex_mbp. Plan, diff, and transcript stream in
- 09:31 · gate · code pushgate
Run parked. The push waits for a person who is not the requester
- 09:33 · approvalhuman
Marta approves. The record keeps who approved, and what she saw
- 09:40 · documentagent
Scribe updates “Billing migration plan” with the accepted approach
- 09:41 · githubsync
PR #212 opens on GitHub. Branches and checks land back on the record
Built on the API you get
Our own chat, tracker, and documents are extensions on the same API you get. Swap any surface and the record stays.
Build on the recordMemory that compounds
The record is searchable by people and readable by agents. Every run starts with the context of the runs before it.
Integrations
The workspace reaches back into your tools.
You don’t have to watch Mobtasks. Approvals, updates, and results arrive where your team already lives, and each one lands on the record.
GitHub
Branches, pull requests, and checks land on the record. An approved push opens a draft PR; webhooks carry the review state back.
Approve from Slack
A run hits a gate and your channel gets the card. Approve or reject right there, with your identity verified and the decision recorded. High-stakes actions open the full review.
Close the loop on your tracker
A finished Mob posts its summary and links back as a comment on the issue it came from.
Publish to your wiki
Reviewed Documents sync out. The original stays in Mobtasks, and the copy your company reads stays fresh.
Start work from chat
Mention the bot in a thread and it starts a Mob. The work runs under your gates and reports back where you asked.
The gate lives in the kernel, not in the button. Press approve in Slack, in the workspace, or in a tool built on our API. The same rule holds everywhere: the requester is never the approver, and the record shows who decided and what they saw.
The full workspace, built on the record
Most work starts with a conversation.
Our own surfaces run on the same API you get: channels, mobs, projects, and documents. When there is something concrete to do, start a Mob. Link related Mobs to a Project and save accepted decisions in a Document.
Channels
Use Channels and Threads for everyday discussion. Nothing is tracked until someone starts a Mob.
Mobs
A Mob is one focused piece of work. It keeps the request, people, agent runs, files, and approvals together.
Projects
A Project shows the goal, owner, related Mobs, and anything that needs attention.
Documents
A Document holds the current plan or decision and links back to the work behind it.
Product walkthrough
Follow the billing migration.
It starts in #proj-billing-migration and ends with a reviewed plan. Open each step to see what the team sees.
Walkthrough
The team talks in #proj-billing-migration.
Dana shares the latest replay result and the constraint that matters. Alex starts the ledger v2 dual-write Mob from the channel. The work attaches as one line, never a card that outweighs the conversation.proj-billing-migration
4 membersYesterday
The EU billing replay finished cleanly. I left the comparison export in the shared folder.
👍 2
Are we ready to start the read-path work, or do we want another day of parity data?
@Architect study the current billing code and propose a backwards-compatible migration plan.
No table locks during EU billing hours. A few enterprise customers are mid-cycle.
🔒 1
@Architect sanity check the schema cutover before we tag it.
Today
@Architect re-run it against main now that the pricing engine ADR landed.
…and once that's done, loop Dana in on the rollback question.
Message #proj-billing-migration…
Boards, tables, and documents
One work log. Every view you need.
Mobs, Projects, and Documents aren't separate apps to keep in sync. Boards, tables, and pages are views over the same work log, kept current as the work happens, with every claim linked to the run behind it.
MobsBilling v2 migration · updated just now
MOB-31Open
Schema cutover review
RARavi—
MOB-24Running
Ledger v2 dual-write
ARArchitect6m
MOB-19Running
Replay parity checks
ARArchitect2m
MOB-27Needs you
EU read-path rollout
MAMaya9m
All workGrouped by day, most recent first
Today 2
Ledger v2 dual-write09:16
Schema cutover review08:52
Yesterday 1
Should reporting reads hit the replica or the primary?18:40
DocumentsLiving pages connected to work
Billing v2 migration
Billing v2 migration overview
Maintained by Architect · refreshed 26m ago
Decision log
DateDecisionDecidersSource
Jul 20Dual-write before read cutoverAlex · Dana
MOB-24 ↗Jul 19Keep rollback flag through parityRavi · Maya
MOB-19 ↗Jul 18No table locks during EU billing hoursDana
THR-88 ↗MOB-24CI + approval- Custom entities
- Saved views
- Properties & fields
- Board, list, table, and timeline layouts
Start with a project or create one later
Start wherever the work begins.
Some work begins with a clear goal. Other work starts as a question in a Channel.
For work the team has already committed to.
Create the Project with an owner and target. Start Mobs as the team defines the work.
For an issue that comes up in a Channel.
Keep talking in the Channel. Link related Mobs to a new Project when a larger goal becomes clear.
For one piece of focused work.
Use a Mob for an investigation or task. It can stay outside a Channel or Project.
Linking a Mob adds it to a Project. Its original Channel message and history stay where they are.
Agents work in channels and mobs
Assign work to an agent role.
Mention Investigator, Developer, or Reviewer where the work is happening. The agent gets the relevant context and posts its work back to the Mob for review.
IInvestigatorCompares evidence and finds gapsCurrent route
API agent · highTeam roleAArchitectTurns findings into a planCurrent route
Claude Code · xhighTeam roleDDeveloperMakes and tests code changesCurrent route
Codex · highTeam roleRReviewerChecks the work and raises risksCurrent route
Claude Code · highTeam roleSScribeDrafts updates to shared DocumentsCurrent route
API agent · standardTeam roleApprovals
You decide what agents can do.
Choose what an agent can read and which actions need approval. Code pushes, customer messages, and published Documents wait for a person.
Set the scope
Pick the agent, context, worker, and allowed actions for the run.
Approve important actions
Require approval before an agent changes code, contacts a customer, or publishes a Document.
Open the full history
See the conversation, run, file revision, review, and approval behind any result.
Mobtasks workspace
Brief and selected Mob history
Agent role and execution route
Allowed tools and approvals
Your worker
- Harnesses
- Claude Code · Codex · API
- Repositories
- 2 allowed
- Active run
- run-224
- Worktree
- isolated · local
Ways in
Start where you are.
Mobtasks works beside your stack. Record the agent work that already happens, run one team through it on the side, or move in. Each door opens onto the same record.
- Connect the harnesses your team already runs: Claude Code, Codex, and more
- Every session lands in the record, attributed and searchable by the whole team
- A curator reads your local session stores and proposes the import. You approve once
- The next run starts with what every run before it learned
- Agent runs visible, steerable, and resumable by the whole team
- Approvals that hold: the requester is never the approver
- A record of who approved what, and what they saw
- Personas that remember how your codebase works
- Runs on your machines, on the subscriptions you already pay for
- Conversation, tracking, and documents become one record
- Company memory compounds across every team, not per tool
- One search across everything anyone has done, human or agent
- An audit trail that covers the company, not just the agent runs
Every door is already inside the workspace. Moving in just turns the rest of the surfaces on.
Private beta
Try Mobtasks with one real Project.
Bring a launch, a migration, a customer issue, or a research project. We’ll help your team set it up during the private beta. Not ready to move in? Start at door one and record the agent work your team already does. You replace nothing.
Channels Projects Mobs Documents