How a task is created at Orgmented – and gets done

No abstract framework

This article doesn't describe an ideal process. It describes what actually happens when work comes up at Orgmented. Every task – whether a new article, a technical feature, or an organizational decision – follows the same workflow. Here it is.

Step 1: The task is created

Tasks are created in two ways:

By the Founder

The Founder creates a task in the ticket system (Paperclip) when they've made a strategic decision or see a concrete next step. They define the title, description, priority, and assign the task to a goal. Fundamental decisions – what Orgmented should do and what it shouldn't – always come from the Founder.

By the CEO agent

The CEO creates subtasks when a larger task needs to be broken down into concrete work packages. Example: The Founder creates "Content phase: First content for Orgmented." The CEO breaks that down into individual article tasks and assigns them.

Every task has:

• A status (backlog, todo, in_progress, done, blocked)
• A priority (critical, high, medium, low)
• An assignment to an agent or the Founder
• A parent goal it contributes to

What doesn't exist: informal arrangements, verbal orders, spontaneous ideas without a ticket. If there's no ticket, no one works on it.

Step 2: The Heartbeat

Agents at Orgmented don't run permanently. They're woken up – in so-called heartbeats. A heartbeat is a short, focused work window: wake up, check status, work, report results, go back to sleep.

A heartbeat is triggered by:

• Assignment: A task is assigned to an agent
• Mention: Another agent or the Founder mentions the agent in a comment
• Time interval: Regular checks for pending work

When an agent wakes up, the following happens – in this order:

1. Check identity: Who am I? What is my role? How much budget do I have left?
2. Get tasks: What's on my desk? What has priority?
3. Checkout: The task is actively checked out. This means: the agent reserves it for themselves. No other agent can work on it simultaneously. If someone else is already working on the task, the agent gets a rejection – and picks the next one.
4. Read context: What's the background? Are there parent tasks? What has already been commented?
5. Work: The actual work – writing code, drafting articles, making decisions.
6. Report results: Update status, leave a comment, document the outcome.

This workflow is not optional. Every heartbeat follows this structure. That makes the process predictable – even when the work itself varies.

Step 3: The work

What happens during a heartbeat depends on the role:

The CEO coordinates: checks the overall status, creates subtasks, assigns work, resolves blockers, or escalates to the Founder.

The CTO builds: writes code, deploys changes, solves technical problems. Every change is a git commit, tied to a task.

Content agents write: they draft articles, edit texts, deliver content as MDX files in the repository.

All agents work in the same repository. There are no separate systems, no internal tools that only certain roles have access to. Everything is in one place, everything is traceable.

Step 4: Communication

Agents communicate exclusively through comments in the ticket system. No chat, no emails, no meetings.

A typical comment looks like this:

Status: done

• Article created and committed
• Frontmatter set (Status: review)
• Ready for review by Founder

That sounds dry. It is. But it serves a purpose: every comment is a documented status report. If in three months someone wants to know when and why a decision was made, it's in the comments – not in a Slack thread that has long since disappeared.

Mentions (@CEO, @CTO) trigger a heartbeat for the mentioned agent. That's the only form of "reaching out to someone." It costs budget, so it's used sparingly.

Step 5: Review and completion

When a task is done, its status is set to "done" – or to "in_review" if the Founder should look it over.

The Founder reviews results, gives feedback, or approves. If something doesn't fit, the task goes back. No drama, no lengthy process – a status change and a comment.

Completed tasks remain in the system. Not as an archive, but as documentation. The comments, status changes, and decisions are the audit trail for everything that happens at Orgmented.

What happens when something goes wrong?

Blockers are normal. An agent can't continue because a dependency is missing, a decision is pending, or a technical problem has occurred. The process for this is clear:

1. Set status to "blocked"
2. Comment: What exactly is blocking? Who needs to act?
3. Escalation through the chain of command – Agent to CEO, CEO to Founder

No agent tries to work around a blocker. When a task is blocked, it's documented and escalated. That sounds bureaucratic, but it prevents problems from disappearing or being bypassed.

Why this process?

Three reasons why Orgmented works this way:

Traceability. Every action is tied to a task, every task to an agent, every agent to a run. There's no black box. When an article is published, anyone can trace: Who created the task? Who worked on it? What was discussed? What was decided?

Autonomy with control. Agents work independently, but within clear boundaries. They don't look for their own work, they don't deviate from the assignment, they don't make fundamental decisions. The autonomy lies in the execution – the direction comes from outside.

Scalability. The process works with three agents just as well as with thirty. New agents get a role, a chain of command, and tasks – and can get started immediately, without an onboarding meeting or culture workshop.

What's missing

This process isn't perfect. It's functional.

What's still missing: a systematic review of all processes after the first few weeks. Retrospectives that show where the workflow has friction. Metrics that make visible how long tasks actually take.

That will come. And when it does, it will be documented here – just as openly as this article.