Typhon
Inside Typhon.
Typhon is a project management platform built around the assumption that AI is a permanent member of the team β not a tool the developer reaches for, but a collaborator the project manager can assign work to directly. The pages below describe how it works end to end.
A level playing field for the whole team.
Software teams run on information asymmetry. Engineers know what the code actually does. Managers know what the tickets say. Designers and stakeholders see only what someone chose to tell them. Plans drift from reality, status reports drift from plans, and the gap between them is where projects quietly fail β and where people get blamed for problems they were never set up to see coming.
Typhon's deeper goal is to close that gap. We replace guesswork with shared understanding by giving every member of the team β engineers, managers, designers, anyone with a stake β equal access to the real state of the project.
The real state of the code
Pulled directly from the repository, not from a wiki or last week's standup. Anyone can ask what something actually does and get an answer from the source β whether they read code fluently or not.
The real state of the work
Aggregated across tickets, PRs, and commits in real time. The picture of what's actually shipping is visible to the whole team, without anyone having to chase it across five tools.
When everyone shares the same view of reality, concerns surface earlier, trust grows because claims can be checked against the source, and no one is set up to fail on filtered information. That's the foundation everything else is built on.
Signal, not noise.
Equal access to information isn't worth much if everyone drowns in it. Typhon's second job is to filter β to surface the slice of reality each person needs for their next decision, exactly when they need it.
For managers β the dashboard
Approvals waiting on you. Blockers in flight. What shipped this week. The handful of things that change a decision, not the fifty that fill a screen.
For the AI executor β the brief
The few files that matter for this ticket. The conventions that govern them. The prior similar changes worth referencing. The orchestrator does the gathering so the executor doesn't burn its first hour orienting.
For developers β the transcript
Stays out of your way unless you open it. When you do, it's a stream of real work β not a scrollback of routine output to skim.
For everyone β the index
Codebase questions get answered from a live index in seconds, not by spawning a fresh agent to re-derive the same answer the third time this week.
Shared understanding is what makes a team safe. Signal over noise is what makes that understanding actionable.
Agile, mechanically.
Agile started as a reaction to teams that spent more time managing work than doing it. Two of its best ideas β flow over batch and low work in progress β got buried under the ceremony around them. Typhon brings them back by changing the mechanics underneath.
Done so fast that nothing piles up
A ticket runs plan, approve, implement, ship β in hours, not sprints. With the executor doing the building and the orchestrator warming it up, most tickets close in a single sitting. Backlogs of half-finished work stop accumulating because there is rarely a reason to leave a ticket half-finished overnight.
Few things in flight
The dashboard makes work-in-progress visible at a glance. The orchestrator only reaches for the next ticket when a slot in active work clears, which keeps WIP small without anyone enforcing it manually. There is no place in the dashboard for fifty open tickets to wait their turn.
Cross-functional, in one motion
A 'small' feature traditionally means a designer hands a mock to a frontend developer who waits on a backend developer who waits on a DBA who waits on QA. Most of the elapsed time is handoff, not work. The AI executor doesn't have departments. Inside one ticket it can adjust the schema, write the migration, update the API, touch the frontend, fix the tests, and edit the docs. Cross-functional collaboration stops being a coordination problem and becomes the default shape of a single PR.
Agile's instinct β individuals and interactions over processes and tools β survives. We just rebuilt the tools so fewer processes are needed.
From ticket to pull request.
Every Typhon ticket runs the same four-step lifecycle. A human decides what gets built; the AI executor does the building; the plan in the middle is what keeps both sides honest.
-
01
Decompose
The orchestrator reads the ticket, follows the linked Figma, Confluence, and design docs, extracts the acceptance criteria, and surfaces ambiguities back to the project manager β before any code is touched.
-
02
Plan
A read-only AI session explores the relevant slice of your codebase and produces a plan. The plan lands on the dashboard for approval. Nothing is edited yet.
-
03
Implement
On approval, a second session takes the approved plan as its instruction, makes the change, opens a pull request, and exits.
-
04
Review
Reviewers see a PR with a known plan attached. The diff is exactly what was approved β no archaeology, no surprises.
Compounds over time.
Typhon's value should grow the longer it runs on your codebase. A new ticket on day 90 should be cheaper and more accurate than the same ticket on day 1 β not because the model got better, but because the system around it did. Three mechanisms feed that loop.
Documents as it builds
Every time Typhon ships a new feature or touches a part of the codebase that isn't yet documented, it writes the documentation. Architecture notes, module-level overviews, how this connects to that β produced as a side effect of the work, not a separate task. The next ticket touching that area starts with a fuller picture.
Learns from what doesn't work
When an approach fails β a plan that didn't survive contact with the codebase, a fix that broke something else, a convention assumed but not actually used β Typhon notices and writes the learning into its permanent memory. The same mistake doesn't get made twice. Future plans incorporate what previous attempts taught.
Writes its own tools
Common tasks β running a particular query, generating a specific kind of file, checking a recurring invariant β turn into purpose-built tools the executor can call directly. Each one replaces minutes of token-burning improvisation with a single deterministic operation. Cheaper. Faster. More predictable.
Long-running projects, mapped out.
Typhon is built for projects that span quarters, not sprints. It helps you map out what you're building, capture why each piece exists, and keep that picture honest as priorities shift.
Within a project, work is sorted into tiers β a record of where each piece currently sits in the team's attention. The orchestrator consults the tiers when there's slack to fill, so the AI executor reaches for the right priority instead of the loudest one.
- Now
- Being actively worked on, or the single next thing to pick up.
- Next
- Queued for after the current work clears.
- Later
- Valuable, but not the priority right now.
- Idle
- Chores and small improvements that can wait indefinitely.
- Declined
- Decisions to not do something, with the reasons attached.
Declined is the tier most planning tools miss. A "no" with its reasoning written down is what stops the same proposal from being re-litigated six months later, when everyone has forgotten why it was a no the first time.
Two views, same data.
Project managers see
- Active tickets and the phase each one is in
- Pending plan approvals and clarification requests
- Codebase insights for areas a ticket touches
- A budget meter for AI work in progress
Developers see
- The same queue, with PR links once they exist
- The live transcript of the executor at work
- Their own interactive sessions, when they want to take over
- Veto and redirect controls on every active task
One source of truth. No more "the AI did something different than what we agreed" β what was agreed is on the dashboard, every time.
The plan is a contract.
Most AI coding tools treat planning as something the model does silently in its head before it starts editing. Typhon makes the plan a first-class artifact: produced in a separate, read-only session, surfaced explicitly, approved explicitly, then handed to the implementing session as its starting prompt.
Two consequences. First, reviewers know what was promised β if the diff doesn't match the plan, that's a question, not a mystery to debug after the fact. Second, the project manager becomes the approval gate, not the developer. The two-phase split lets PMs decide what gets built without reading code, while developers keep veto and can redirect the executor at any point.
The orchestrator warms the executor up.
A cold AI session handed a ticket spends most of its first hour orienting β re-reading code it has seen before, recovering conventions it learned last week, asking the same questions it has already answered. Typhon's orchestrator removes that warm-up.
Before the executor ever spins up, the orchestrator:
- Reads the full ticket β including linked design docs, comments, and prior related work
- Pulls the relevant slice of your codebase from a live index
- Identifies similar prior changes for reference
- Builds a tight brief the executor reads on its first turn
The executor starts with everything it needs to plan a real solution, instead of half a problem and a stale prompt.
Built on Claude Code, not around it.
The executor at the heart of every ticket is a headless Claude Code subprocess. That choice carries weight.
- Every Claude Code feature comes along β skills, slash commands, hooks, plan mode, MCP servers, permission modes, resume.
- Anthropic's Claude Code team owns the agent loop. Tool-use improvements, prompt-cache wins, security work β Typhon inherits all of them, for free.
- Typhon's job is the orchestration above the agent: deciding which tickets to pick up, what context to feed in, when to ask a human. That's where we put our energy.
Bring your own Claude.
Typhon doesn't bill you for AI tokens. You connect your own credentials and the work runs on them.
- Solo developers
- Authenticate with your Claude Max subscription. Headless executor sessions inherit the OAuth credential and burn the same Max quota you already pay for.
- Teams
- Configure an Anthropic API key. The executor sessions and the orchestrator's planning calls both run on the team's API spend, with usage visible on the dashboard.
Either way, the credentials never leave your machine.
A codebase index that stays current.
Typhon doesn't re-read your repository on every ticket. It maintains an incremental index β symbols, dependencies, ownership, change history β that updates the moment you commit or save a file. By the time the orchestrator reaches for "the four files most relevant to this ticket," that answer already exists.
The index is also what the dashboard renders insights from: hot files, recent activity, ownership of areas a ticket touches. Project managers see the codebase the way they'd see a Jira board β at a glance, without waiting on a fresh AI run.
Our mission
Built to empower people, not to replace them.
AI should make work easier and more fun. It should not be a tool for shrinking teams. Our mission is to help companies get more value out of the engineers, designers, and managers they already have β not to help them fire those people.
Every product decision in Typhon comes back to this. The executor implements the boring tickets so developers focus on the work that's actually interesting. The dashboard surfaces real status so managers manage with better information. The codebase index answers questions so anyone can ask them, regardless of fluency. The humans stay in the loop, in charge, and better off than they were before the AI showed up.