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 — an active goal to push forward, 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

Broadly, three kinds of trigger:

• Goals. The goal loop is always working the direction you’ve set. Set a sharp goal and the loops orient their attention around it — this is your main steering wheel.
• Signals from your tools. When you connect a tool through an integration — say Sentry — a new error spike or a performance regression can wake the relevant loop. The loop treats the signal as a starting point and investigates the code behind it.
• Periodic sweeps. On its own cadence, Tekk takes a broader look at the project to surface improvements nothing else flagged.

Signal loops are opt-in per workspace — you choose which ones run — while the goal loop is always on. You turn loops on and off in the app.

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 goals and your feedback.