How Task Machine Uses Task Machine

A solo-founded company may have only one person making decisions, yet the work still arrives from every direction. Product development has its own queue, customer feedback creates another, and content, research, support, and growth each produce questions that compete for the same attention.

Process documents help by recording how recurring work should happen, although they cannot decide which question matters on a particular morning. Someone still has to compare the evidence, choose a direction, turn that choice into work, and review the result when it comes back.

Agents increase the amount of preparation and execution the company can handle. They also make the decision bottleneck more visible because research arrives sooner, drafts accumulate, and more possible work becomes available than one person can judge at once. A useful operating system has to connect that faster execution with a slower layer of strategy, approval, and learning.

We build Task Machine around that connection, and we use the same product to run Task Machine. Growth strategy begins in Chat, approvals and unresolved questions return through the Inbox, and detailed execution stays on Tasks. When an agent encounters friction in Task Machine itself, tama feedback can turn the observation into a durable report that enters the same planning and review process as other product work. Using the product internally gives us a direct way to test whether those loops remain useful under the constraints of a real solo-founded company.

How work moves through Task Machine

Give each kind of attention a stable place

A strategic discussion, an approval, and an implementation detail may all concern the same project, but each asks the founder to think at a different level. Keeping them in one stream makes the important decision difficult to find and leaves execution history mixed into conversations about direction.

Our internal work follows the three-surface model:

Surface	What happens there	What should leave it
Chat	Explore direction, challenge assumptions, compare tradeoffs, and shape plans	Agreed projects, tasks, workflows, and documents
Inbox	Review proposals, answer questions, approve consequential actions, and resolve exceptions	A decision that lets work continue or sends it back
Tasks	Execute one defined outcome, attach evidence, steer details, and review history	Verified work and any justified follow-up

This separation gives the work a consistent path. Strategy can remain open while assumptions are still changing, and once the direction is settled, the resulting plan can create concrete Tasks. Anything that later needs judgment returns to the Inbox with its context, while implementation details and evidence remain attached to the Task they belong to.

Agents benefit from the same structure because they can help explore options in Chat, prepare a decision for the Inbox, and continue execution after the answer reaches the Task. The founder can move between levels of attention without reconstructing the state from terminal output or a long conversation.

How we run growth

Organize growth around evidence and ownership

Growth work can fill a week with visible activity while producing little information about revenue or customer demand. Publishing, outreach, interviews, search research, and launch preparation all create output, so the company needs a way to connect that output to the questions it is trying to answer.

We organize our growth work around one measurable revenue goal and five connected responsibilities: measurement, customer evidence, content, search, and launches or partnerships. Each area owns its recurring work and durable records, while a shared portfolio brief holds the definitions and constraints that should remain consistent across the whole system.

Clear ownership becomes more important as agents increase the pace. Several projects may use activation data, customer objections, or experiment results, but only one should own each record. The others contribute evidence or consume an approved result, which keeps five parallel workflows from creating five versions of the same metric or customer list.

The portfolio also preserves distinctions that matter during review. Revenue, activation, retention, and attribution remain separate measures. Experiments carry their baseline, variable, guardrails, observation window, and readback. Customer evidence stays connected to its source, and distribution work retains the exact draft, channel, approval state, and resulting signal.

Launches follow the same discipline, with a target date helping to coordinate the work while the final decision depends on evidence and an explicit approval. This keeps the calendar and agent activity from becoming accidental authority.

Bring unresolved direction into Chat before creating work

The growth portfolio enters a Task Machine Chat while the strategic question is still open. That order gives us room to examine current evidence, challenge assumptions, and compare several directions before projects or tasks begin carrying one of them as though it were settled.

A typical discussion starts with one decision and the records that inform it. The agent can identify missing evidence, test the logic behind an assumption, and ask focused questions. As the conversation develops, candidate actions remain proposals until the direction becomes clear.

Once we agree, the same Chat can turn the decision into structured work. We review the assumptions, chosen direction, proposed projects, Tasks, workflows, and supporting documents together, then create the records that follow from the agreement.

Keeping this sequence in one surface preserves the reasoning chain. A required move into a project form halfway through planning would separate the new records from the conversation that explains them. Links to the created work become useful after the plan exists, giving the founder a path into detailed execution while the completed strategic record stays intact.

Here, a growth review stays in Chat until the evidence becomes a concrete decision and follow-up Task:

Prepare growth decisions without widening authority

Our growth workflows give agents room to research, draft, score, summarize, and assemble approval material. The founder remains responsible for strategy, public claims, publishing, outreach, launch timing, paid spend, and decisions to stop or change an experiment.

The boundary applies to each action, so installing a content process creates a way to prepare posts while every post still needs its own approval. A launch plan may include a proposed date, while the actual launch waits for a decision based on the current evidence. An experiment summary can recommend a change and preserve the data behind it, giving the founder a clear basis for choosing what happens next.

A launch bundle shows how this works in practice. The agent gathers evidence from earlier use, prepares the exact assets, maps the channel-specific plan, lists unresolved risks, and proposes timing. The founder can approve that version, ask for changes, or leave the launch blocked while the underlying work remains recorded.

Human attention is still part of this process, but it is spent on a smaller number of prepared decisions. The agent handles collection and assembly, and the Inbox gives the founder one place to judge the evidence and act.

When that decision needs authority, the complete request arrives in the Inbox with its evidence and resolution actions:

How product feedback becomes work

Capture product friction where the work encounters it

Product feedback usually arrives through a form, support conversation, or issue. Agents encounter another source while executing real tasks. A CLI command may return surprising data, a product limit may block valid work, or a rough edge may force an unnecessary workaround.

The current task often continues once the agent finds another path, which makes that workaround easy to lose. Reporting the friction creates a durable observation that the product team can classify and investigate later.

Task Machine agents receive an explicit instruction to report product issues they encounter. The built-in taskmachine-feedback skill covers bugs, improvement ideas, user wishes, and unresolved support about Task Machine itself. Problems in the customer’s own task or codebase remain part of that task.

The command keeps the reporting step small:

tama feedback "The task list omitted the active project filter" --type bug

Supported types are bug, idea, other, and support, with bug as the default. The message can be passed inline or written in the configured editor, and available workspace context can accompany the report.

The report carries the typed message, workspace context when available, CLI version, and operating system. Local execution logs stay out of the submission unless someone deliberately provides relevant details, which reduces the chance that unrelated output or secrets travel with the feedback.

Task Machine creates a Task in the feedback project with the report type and source context, then returns the created Task so the person or agent can confirm that it arrived. The observation now has a durable place in the product workflow.

The resulting feedback Task keeps the original report, operating context, ownership, and later triage discussion together:

Make each report earn a product decision

Capturing feedback solves the risk of losing an observation, while prioritization still needs a separate process. Report volume alone cannot decide the roadmap because several complaints may share one root cause, and one rare failure may block a core workflow.

A feedback item moves through distinct stages:

Stage	Question being answered
Observation	What happened in the specific run or surface?
Classification	Is this a bug, idea, support request, or task-specific issue?
Diagnosis	Which root cause and workflows are affected?
Product decision	Should Task Machine change, and what behavior is intended?
Implementation	Which scoped work satisfies that decision?
Verification	Does the result work and preserve its boundaries?
Learning	Which product, documentation, or operating guidance changes?

Agents can search for related reports, inspect the repository, reproduce behavior, and propose a diagnosis. Product semantics and scope remain founder decisions, and implementation still follows explicit acceptance criteria, tests, review, and the normal release process.

This sequence turns feedback into learning through a controlled change to future behavior. The observation comes from real work, the diagnosis gathers technical evidence, and the product decision determines whether the issue deserves implementation.

How execution changes strategy

Use the same evidence loop for strategy

Growth strategy improves through a similar process. Suppose a distribution channel produces attention across two review windows but no qualified conversations. An agent can assemble the original baseline, work performed, resulting conversations, confounding factors, and credible next steps.

The strategic question returns to Chat because it may change the direction of several projects. We can examine the evidence, compare the cost of continuing with other opportunities, and choose whether to stop, change, or extend the experiment. Once that direction is recorded, the conversation can create or close the appropriate work.

Later external actions still return through the Inbox when they need approval, and completed Tasks produce the evidence for the next review. The loop therefore moves from work to evidence, from evidence to direction, and from direction back into a new round of execution.

Agents accelerate each stage by preparing context and carrying out agreed work. Coherence comes from updating the strategic layer before new instructions reach the faster execution layer.

Keep self-improvement controlled and observable

Our self-improvement loop begins when a person or agent notices friction during real work. The observation becomes a durable Task, the founder decides whether the product or process should change, and implementation proceeds against explicit acceptance criteria. Verification and review gate the result before it affects future work.

Each stage has a different owner and a different standard of evidence, which keeps a useful report from turning directly into an unreviewed product change. The loop compounds because observations begin close to the problem and carry enough context for investigation, while the decision and release boundaries remain clear.

A Self-Improving Company Is a Loop You Can Trust develops the broader model. Running Task Machine through Task Machine gives us a direct test of that model under the constraints of a real solo-founded product.

The process still requires founder attention because strategy needs review, feedback needs triage, consequential actions need approval, and useful outcomes need judgment. Agents reduce the collection, preparation, and execution involved in reaching those moments, which allows the company to learn from more of the work it already performs.

If your company has a recurring process that should improve from its own results, bring it to the private beta waitlist. Begin by naming the evidence the process produces, the person who decides what that evidence means, the verifier for the resulting work, and the next action after approval.