An open source Tasklet alternative earns its keep in the diffs

Tasklet's prompts copy across in an afternoon; the part worth paying for is the diff a teammate reads before an agent changes.

Tasklet gets a first agent running in minutes, and Kortix is the open-source alternative your team runs itself. The prompts, skills and tool lists come across as text, so the copying is a short job. What deserves the budget is the year after it, when an agent's instructions change and somebody has to read the change, argue with it, and put it back.

What Tasklet sells, and sells well

Tasklet's homepage promises "Automate any business task with AI agents that run 24x7" (Tasklet). It is a hosted product, with a macOS desktop app you install from a .dmg (Tasklet download). The agents run inside Tasklet's own cloud environments and keep going after you close the tab. Neither the homepage nor the pricing page describes a self-hosted install, checked October 2026.

• Approvals you configure. "Decide what your agents can do on their own, and what they need permission for. They'll reach out when they need your approval." (Tasklet)
• Reach into awkward systems. Tasklet says it connects to thousands of SaaS tools, MCP servers and any API, private ones included (Tasklet).
• One model menu. "Tasklet gives you access to leading models from Anthropic, OpenAI, Google, and open-source labs in one plan." (Tasklet pricing)
• Usage pricing without seat fees. Plans start at $25 a month for 10,000 credits and $100 for 40,000 (Tasklet pricing, October 2026). Above that, a plan scales to any amount up to $10,000 a month, with unlimited team members on one pool.

None of that is a knock. A team with three agents and nobody on call gets a working system the same afternoon, and the vendor patches it overnight. Tasklet also states it is SOC 2 Type II compliant, which is the kind of answer a security review asks for early.

What moves as text

Every agent you built there is described in words somewhere in the product. The instructions say what the job is and what a finished answer looks like. The saved skills carry the procedure for one queue, one report or one inbox. The tool list names the apps it may call and the account behind each call. A fourth setting decides which steps run alone and which come back to a person, and Tasklet names that setting in the same sentence about approvals.

Copied into a text editor, those four give you most of an agent. The rest is judgement: which examples mattered, which recipients were off limits, what the old version got wrong in March. Someone who has watched the agents work can rebuild that in a day, and a bad reconstruction shows up inside the first week.

What the repo holds, and what it does not

Kortix is the open-source CompanyOS: your agents, their skills, your company memory, and every connector in one git repo you own, with the agents working on real cloud computers. A project is one git repo, and its agents, skills, memory and connector settings are files in it (Kortix docs).

The part that decides what the agent may do is seven lines, the worker entry plus the line that makes it the default:

default_agent: worker
agents:
  worker:
    mode: primary
    permission: allow
    prompt_file: agents/worker.md
    tools: all

default_agent names the agent a session opens with. prompt_file points at the markdown holding its instructions. tools: all says what it may call, and permission: allow sets the default for calls that have no rule of their own. A team that wants a narrower agent edits one line, and the edit arrives as a diff.

The repo does not hold the run log. Sessions and their transcripts live in Kortix, and the audit log sits with the account rather than in the project's files (Kortix docs). Every action is recorded. Reading, exporting and streaming the audit log depend on the plan. Host your own instance and the records sit on your machine; run on Kortix Cloud and they sit in your account there, at the tier you bought.

That splits the job in two. The text moves today, and the history is an export you take from whichever instance runs your agents, on a schedule you set, and keep wherever your audit lives.

The diff the old console never gave you

The case for doing this is the second year, not the first week. An agent that runs a real job drifts. A skill picks up a step nobody needed, a prompt grows a paragraph after an incident, memory collects a fact that was true in June. In a settings screen those edits are saves, and the person who pressed save is the only witness.

Here an agent that changes its own skill or memory opens a change request. Session work reaches main through a change request. Merge is default-deny for agents. A person reads the diff, merges it or sends it back, and the merge keeps the change and its review in one history. One isolated sandbox per session. Each session has its own isolated machine and branch. A bad run is one branch to throw away.

Three habits follow from that, and none of them needs a meeting. You can revert a prompt to the version that worked. You can read last quarter's instructions instead of trusting a memory of them. You can hand a new colleague the last twenty changes to an agent and let them see how it got here.

The order that works

A migration goes wrong when the account closes first. This order keeps the record, the text and the access in the right sequence.

1. Export the run history first. Ask for the log in a form you can open without the product. Then write down the questions your finance team will put to it at quarter end. If the export is thin, get the answer in writing before the renewal date.
2. Copy the text into a repo. One agent per commit. The commit history becomes the migration's own record, and the first agent tells you whether the reconstruction is honest before you touch the other four.
3. Reissue every credential. The connection grants in the old product end with the account. Issue new ones for the new system, scoped to its own accounts, and revoke the old set in the same week.
4. Run one real job beside the old one. Pick work whose output somebody reads that week. Run a cycle on both systems and compare the results before you trust either.
5. Cancel last. Close the account once the first job clears and the archive opens on a laptop with no vendor login.

Where Tasklet wins, and the other names in the search

The honest case for staying is short. If the work is two or three shallow agents, nobody on the team wants to read a prompt before it runs, and $25 a month covers the usage, Tasklet is the cheaper month. A migration costs days, and those days buy a review process nobody has asked for yet.

The other names in the same search answer one question differently, which is who holds the running system. Lindy is a hosted assistant with memory kept in plain files inside its workspace, from $29.99 per person a month (Lindy). Zapier Agents run hosted across 9,000+ apps (Zapier Agents). n8n runs workflows and agents on your own server or on n8n Cloud, with workflow history and an audit log (n8n). Dify self-hosts with Docker Compose or runs as a cloud workspace (Dify docs). OpenClaw is an open-source assistant with no hosted tier, installed on your own machine (OpenClaw). OpenHands runs coding agents locally in Docker (OpenHands docs). Kortix is the one here that keeps the agent definitions in a repo your team owns and lets you host the instance that holds the log.

Side by side

When to pick which

More from the blog: open-source Lindy alternatives and open-source Manus alternatives.

Kortix is free to start, and self-hosting costs nothing. Clone the repo, run one session, and open the change request that proves the review works: Get started with Kortix.