Team input
Work starts with the team: operations and sales raise what customers hit, product decides what it means, and the result is written down as a task — assigned to a developer, or to an agent.
The problem
Agents made writing code fast. Deciding what to build stayed manual.
AI coding agents make writing code fast. They don’t make deciding what to do, which project rules apply, or how the result gets recorded any easier. Context gets lost between chat sessions, scattered terminal history, and task notes that live nowhere in particular. The bottleneck today isn’t code generation — it’s context control.
How it works
One loop: team input, objective, approved plan, scoped task, agent session, recorded result.
Spec-Driven Development is the order this loop enforces: the specification is written and approved first, tasks are derived from it, and an agent implements against that specification rather than against a prompt.
Objective
You describe a goal in objective-refinement chat — it loads current task state, the project’s architecture knowledge, and prior context.
Plan approval
The chat turns the goal into one or more scoped tasks. A human approves the plan before anything is built.
Scoped task
The task carries its approved specification, dependencies, priority, and the necessary fragments of the project knowledge base.
Agent session
An agent launches in a terminal session pre-configured with the project’s MCP server and implements the task.
Result recorded
A resolution comment, updated architecture documentation, and token and cost data land back on the task. The board moves forward.
Task board
The task record an agent reads and writes, not a card it can’t see.
Board, backlog, and sprint views all come from one task record — the same one an agent reads over MCP and writes back to when the work is done. Dependencies and priority set what an agent picks up next; each task carries the necessary fragments of the project knowledge base.
Landing page L1–L15 sections
Board → Backlog → Sprint 12
landing-page
css
tt-website-laravel
AI agent execution
Agents run from the task, after a human approves the plan.
An objective goes through a planning chat before any code is touched — a human approves the plan, not just the goal. Once approved, Claude Code and Codex launch from the task in a terminal session with the project’s MCP server already wired in. Other agents get the same task context through the REST API.
Spec-Driven Development is what makes that approval gate load-bearing: the approved plan is a written specification, it stays on the task the agent reads over MCP, and the resolution comment that comes back is checkable against it.
$ $ tipatask session start TPT68
plan approved — starting agent session
$ $ update_task TPT68 status=in_progress
resolution comment posted — status=completed
Sprints
Sprints set the order agents pick up work in.
Priority, dependencies, and status decide what’s next. The sequence an agent follows in a terminal session is the same one a human sees on the sprint board.
Sprint 11 — complete
Sprint 12 — active
Scaffold standalone Laravel site
Landing page L1–L15 sections
Multi-project workspace
One desktop app, every project you work on.
Ships as a macOS desktop app today. It runs next to the repositories it manages, with one cross-project view across every project you work on.
tipatask
6 active
apppixies-site
2 active
internal-tools
1 active
MCP and architecture memory
Architecture docs your agents call through MCP.
MCP (Model Context Protocol) lets an agent call a project’s tools directly, instead of having context pasted into a prompt by hand. Tipatask’s tasks, comments, and architecture docs are all exposed this way. Each finished task writes its architecture notes back through the same MCP server the next task’s agent reads from.
$ $ mcp call pull_knowledge
→ architecture doc returned
$ $ mcp call push_knowledge
→ docs updated for the next agent
What makes us different
Built around agent-executed work, not retrofitted for it.
Both contrasts reduce to one discipline: Spec-Driven Development. The unit of work is a specification a human approved before execution, and that is what makes the result reviewable — a reviewer checks the implementation against the specification, and the specification against the objective it was derived from.
Against generic AI app builders
Prompt-to-app tools optimize for producing something that runs quickly, with the underlying work largely invisible — no durable plan, no record of what was tried and rejected. Tipatask governs how real, ongoing work gets planned, executed, and reviewed, task by task, with a resolution comment, updated architecture docs, and cost data attached to each one.
Against cloud task boards and AI workspaces
Most task tools were built for humans coordinating with humans, with AI added afterward as a chat feature. Tipatask starts from the task record itself: designed so an agent can read and act on it directly through MCP, with architecture context and execution history as first-class fields, not a bolt-on.
Who it’s for
For developers already running agents every day.
Solo developers
Context gets lost between chat sessions, scattered terminal history, and task notes that live nowhere in particular. Tipatask remembers the project across sessions — the plan, what got tried, the architecture — without a workflow heavier than the work itself.
Engineering leads
Task specs an agent can actually execute, not just a person can read, plus visibility into what agent-assisted work actually did — comments, resolution notes, and updated architecture documentation that make it reviewable the same way human-produced work already is.
AI-native founders
One surface for objectives, architecture context, and execution — not an enterprise work-graph tool built for a large organization, and not a generic scheduler with nothing to say about code.
Testimonials
What people say
Nothing of that would be required, you know.
Easy peasy!
Team work is the key.
Delegation is all about trust.
No more tasks hanging.
I love the big-picture view.
Roadmap
Windows and Linux first, then isolated execution and mobile.
Planned — not yet shipped
Now
Full support beyond macOS — the single biggest adoption barrier for teams not all on one platform.
Next
Agent work running inside an isolated container, so it can act with fewer manual confirmations without risking the host machine — plus a mobile app for visibility and remote control over that work.
Later
Richer task structure for larger projects — branching tasks and nested sub-boards — followed by managed cloud hosting, and eventually self-hosted Git repository management built into the workflow.