How the loops work

Loops are what make Tekk self-improving rather than reactive. A loop is an autonomous routine that runs on your project, looks for a specific kind of improvement, and — when it finds something worth your time — brings you a proposal. You never lose control: nothing ships without your greenlight.

The shape of a loop

Every loop follows the same arc:

1. A trigger fires. Something gives the loop a reason to run — code that changed since it last ran, a signal from a connected tool, or a periodic sweep of the project.
2. Tekk investigates. The loop reads the relevant parts of your actual codebase and the workspace’s documents (what the product is, who it’s for, how it makes money), so its reasoning is grounded in your project, not in generic advice.
3. It drafts a proposal. If the loop finds something real, it writes a proposal that explains what it noticed and what it would do — sized to be a coherent piece of work, not a vague hunch.
4. You decide. You accept (it becomes a drafted spec on your board) or decline with a reason (which steers future loops away from that direction).

What triggers a loop

A loop runs in wakes. Three things give it a reason to wake:

• Your code changed. Every loop’s starting point is the delta since it last ran — the files that changed, ordered by how much of the system depends on them, and what those files feed into. It reads what changed and follows it to what it touches, the way a senior engineer returning to a codebase does; it does not re-audit the whole repository every time.
• A signal from your tools. When you connect a tool through an integration — say Sentry — a new error spike or a slow transaction can wake the loop that owns it. The loop treats the signal as a starting point and investigates the code behind it.
• Part of its area has gone unexamined for too long. On its own cadence, a loop takes a broader look at the highest-stakes surfaces in its domain, so nothing sits unreviewed just because it stopped changing.

Loops are opt-in per workspace — you choose which ones run. You turn loops on and off in the app.

What a loop is made of

Each loop is a shelf of skills: a short file that says what the loop is and what counts as a finding in its domain, plus two to five self-contained methods — one per kind of question. A run reads its brief, then opens exactly one skill and works it end to end, and records which one it used so the next run knows which methods have really been exercised. The full list of loops and the skills on each shelf is on Loops and their skills.

Propose first, act second

The important property is the order: Tekk proposes, you dispose. Loops don’t silently change your code. They produce reviewed suggestions, and the accept/decline decision is always yours. Declining isn’t wasted — the reason you give is how you teach Tekk what’s noise for your project, so proposals get sharper over time.

Accepted proposals become specs, and from there they flow like any other work on the board — including being implemented from inside your coding agent through the MCP server.

What’s running under the hood

• Claude. Tekk’s reasoning runs on Anthropic’s Claude models.
• Your repo, in context. Loops read the real code of the project they’re attached to, so a proposal points at the files it actually concerns.
• Your connected tools. Through Composio, loops can see signals from the SaaS tools you connect, so the software can improve in response to what’s actually happening in production.

We keep the internals of scheduling, prioritization, and cost management out of these docs — but the contract you can rely on is simple: grounded in your project, always reviewed by you, steered by your feedback.