Moving your agents off Tasklet into an open‑source repo

What you can take with you

Tasklet is a managed cloud product: agents run in Tasklet’s isolated cloud environments and keep working after you close the app. That is a good reason to buy it, and no reason to feel trapped by it. What you wrote there is text, and text moves.

Four kinds of text. Each agent’s prompt, which says what the job is and how you want it done. The skills behind it, meaning the know-how and the examples it reads before it starts. The list of tools it may call, and which account sits at the other end of each one. And the rules about autonomy, meaning which steps it takes alone and which come back to you. Tasklet describes that last part in its own words on tasklet.ai: "Decide what your agents can do on their own, and what they need permission for. They’ll reach out when they need your approval."

Collect those four as plain files, one folder per agent, before you sign up for anything. Do it from the settings screens while the account is open, and do it generously. A screenshot is a last resort. Retyping four lines this week costs less than an argument in March about which calendar an agent could write to.

What does not travel

Three things stay in Tasklet’s cloud, and one of them needs a decision before you cancel.

The first is the run history: what each agent did, when, with what input, and what came back. The second is the live configuration of each connection, which is a credential plus a mapping held on Tasklet’s side. The third is the credit balance, which is money already spent on a service you are leaving.

Only the history deserves a plan. If a customer, an auditor or your own finance team will ask what happened in July, copy what you need while you still have access, and put it somewhere the company keeps. Rebuilding an agent takes an afternoon. Reconstructing a quarter of activity that no longer exists takes longer than anyone budgets for.

The layout you migrate onto

A Kortix project is a git repository with a manifest at its root. kortix init builds one from the starter, and the starter’s tree is the whole map:

my-agent/
├── kortix.yaml   the manifest (kortix_version: 3): skills, agents, one trigger, secret names
├── agents/       the prompt of each agent: kortix.md, harness-reflector.md, session-reviewer.md
├── skills/       11 skills, one folder each, with a SKILL.md
├── memory/MEMORY.md  the project memory
├── README.md
└── .gitignore

Each line does one job. kortix.yaml declares your agents, the grants each one holds, their triggers, and the names of the secrets they need, never the values. agents/ holds one markdown file per agent, and that file is the prompt. skills/ holds a folder per skill with a SKILL.md inside it. memory/MEMORY.md is what the project carries between sessions, and it is the one file on this list a person should reread monthly. The reference for every key is in the developer docs.

The map from what you collected is almost mechanical. One agent in the old product becomes one file in agents/. One block of saved instructions becomes one folder in skills/. One connection becomes a connector declared in the manifest. That is the whole difference in shape: a dashboard you log into becomes a repository you clone.

Five steps, and what each one produces

1. Collect the text. For every agent: prompt, skills, tool list, approval rules, schedule. Produces one folder of plain files per agent, readable in any text editor.
2. Scaffold the repo. kortix init my-agent, then cd my-agent, then kortix ship. Produces a repository you own, a manifest, and a validated commit on a branch.
3. Write the agents and their skills. Move each prompt into its own file under agents/, each skill into its own folder under skills/, and declare both in kortix.yaml. Produces a diff a teammate can review line by line, which is the thing you could not do before.
4. Reissue the credentials. New keys, scoped per system, set through the CLI. Produces an agent that reaches the same tools with keys you issued and can revoke.
5. Run one real job and land it. One session, one task you actually needed, one change request merged by a person. Produces evidence on the branch that the new setup does the work.

The first four steps produce configuration. The fifth produces proof, and it is the one to slow down on.

Rotate the credentials, do not copy them

The step people skip decides whether this was a move or a duplicate. An API key copied across carries every property it had in the old product: a scope somebody chose months ago, reach into every board and mailbox that scope covered, and a use history you cannot read.

Issue new keys instead. Give each connector its own credential, limited to the systems that agent really needs, and store the value in the secret store so the manifest holds only the name. Where a connector supports it, let Kortix broker the credential: connector credentials are brokered server-side and never enter the machine, so the key is not sitting in a working directory an agent can read.

Then revoke the old keys on Tasklet’s side, after the overlap rather than before it. Two live copies for a week is a controlled risk. Two live copies for a quarter is how a migration becomes an incident.

Prove it before you cancel

Kortix ships a check for the boring failures. kortix doctor verifies your login and the project, starts a throwaway session, sends it a ping, waits for the agent’s reply and deletes the session, exiting with a failure when a check does not pass. That is a faster answer than reading an install guide twice.

Then run one job that matters on both systems, side by side, for a week. Compare the output each one returns. On the new side the work arrives as a branch: session work reaches main through a change request. Merge is default-deny for agents. So the approval you cared about in the old console still exists, and a person still gives it. When a week of those runs looks right, cancel.

When not to migrate

If you have two shallow agents and nobody in the company wants to read a prompt before it goes live, Tasklet at $25 a month is the cheaper month. Moving would be ceremony. If your agents only work because their approval steps and their data all meet inside Tasklet’s cloud, and you have nobody to run a server, wait until one of those two facts changes.