Roadmaps and Cloud agents
Two weeks ago, in the [agentic surfaces update](/lab-notes/agentic-surfaces-summer-update), we committed to having a written path for CompX and the COMPX token by the middle of August — the 15th, to be precise. That date came and went with the CompX v2.5 roadmap published, so this note is really about two threads that showed up at the same time: why we wrote the roadmap, how we got it out on time, what the early response has been like, and what it actually commits us to build; and, less flashy but just as important for how Neon Forge works now, the Cursor / Grok / Linear loop we've been wiring across the agent stack and already using to implement that roadmap.
Why CompX v2.5
CompX has always sat at an awkward intersection. We built DeFi rails on Algorand — lending, staking, payments, a concentrated liquidity AMM — and we kept them running because they're useful infrastructure and cheap enough to leave live, even though none of that is where growth lives in 2026. Algorand DeFi TVL is thin, better-liquid lending venues exist elsewhere, permissionless staking demand cooled, and payments never quite reached product-market fit. Pretending unused markets are the product doesn't help holders or builders.
Meanwhile something else under the CompX brand started to look real. Canix402 and Amarok are agent-native APIs paid in USDC via x402, which agents can discover, pay for, and use for research and execution quotes. Brownie Bot already stewards the community treasury against Canix, and Ghillie is on prediction markets through Amarok. That's a different kind of product than a DeFi dashboard, sitting on a rail that didn't exist when CompX started.
So the thesis for v2.5 is fairly narrow: COMPX is the token of the CompX agent stack, and you stake it to direct monthly x402 revenue among ops, stakers, and repayment. DeFi is no longer leading the story, but it's still important infrastructure for the new direction. Engineering attention, branding, and governance bandwidth go to agents, reporting, and token utility that connects real USDC to people who show up to vote. We're also keeping a promise we already made: repayment for users affected by the February exploit remains a first-class destination for funds.
How it landed on the 15th
Publishing a roadmap on a date you announced in public mostly means deciding how much you're willing to leave unsaid. We locked the product principles early — one monthly question, three revenue lanes, floors and a ceiling, must-vote-to-earn for the staker share, Brownie out of the monthly ballot, epoch maths deferred — and left exact snapshot rules, voting-power formulas, and distribution plumbing for later. Waiting for finished contracts would have meant we were still writing; publishing a contract we hadn't pressure-tested would have locked the wrong details. A public commitment forces scope discipline, so we wrote the principles, invited feedback, and moved on to building the surface that matches the story.
What it entails
CompX leads with agent APIs and agentic payments — Canix, Amarok, and what comes next — while DeFi stays live in the background. Each month, net USDC from x402 products is split three ways between Ops, Stakers, and Repayment, COMPX stakers vote on that split, and only stakers who vote that month can claim from the Stakers lane. Early months may be small, and we'll still publish the numbers.
The split has floors and a per-lane ceiling: Ops at least 30% and at most 60%, Stakers at least 15% and at most 60%, Repayment at least 20% and at most 60%, always summing to 100%. The proposed default, which is also a candidate if turnout is too low, is 50% Ops, 25% Stakers, 25% Repayment. There is no minimum dollar payout, so a small month is still a percentage split.
Governance in v1 is a single recurring question each month. You stake COMPX in a dedicated governance pool, vote on the split, and claim USDC if you voted. Miss the vote and you miss that month's Stakers share, though you can still stake and vote next month. Ops gets a plain monthly cost card so the allocation is tied to documented costs rather than a vague team sink. Brownie remains a long-term community treasury asset and stays out of the monthly ballot until PnL is clearer; any material use of that treasury should be a separate, occasional decision. v1 also stays away from monthly debates over every DeFi parameter, folding uncertain bot profits into the split, printing COMPX emissions to fake TVL, or shutting DeFi down.
The response so far
The response has been good, if not hyperbolic. Token utility changes can go quiet or get treated as a price thesis, and what we've seen sits somewhere in the middle: people reading the floors, asking whether must-vote-to-earn is the right bar, and poking at low-turnout fallbacks. Those are the questions we asked for in the announcement — whether 30 / 15 / 20 and the 60% ceiling are balanced, whether must-vote-to-earn is the right gate, whether a failed quorum should fall back to last month's split or a fixed default, and what belongs on the Ops card. We'll fold useful answers into the design before contracts freeze.
What has already started
Work has already started on catching the product surface up to the story. The frontend is being recast around agents first, so the path is use the agent APIs, stake COMPX to govern revenue, and find DeFi if you need it. Nav and marketing are shifting so Canix402, Amarok, and governance are the growth surface, while lending, the staking factory, and Payments stay available but backgrounded. clAMM is being unrouted from the public UI while the code stays in the repo. /app/governance is becoming a real destination that explains the announced monthly vote — principles, floors, eligibility — even before live contracts, and a mock COMPX governance stake card is landing with a Coming soon stake action so holders can see the product shape without a wallet popup that does nothing.
In parallel we are planning Phase 1: an upgraded injection reward pool for governance staking, with persistent COMPX stake, monthly USDC injection after the vote, and claims gated on vote participation, plus metering and payouts for x402 revenue. Epoch schedule, snapshot rules, and claim docs still need to be published before the first live vote, which is the order we want — surface and story, then contracts, then a live ballot once the public rules and addresses are clear.
The other story: cloud agents
Publishing a roadmap is one kind of acceleration, and shipping against it across five active repos plus CompX itself is another. Over the past couple of days we've been running a loop that still feels slightly unreal day to day: Cursor cloud agents, Grok, and Linear wired so checklist work becomes tickets, tickets become implementation plans, and plans become pull requests, with humans still owning assignment, review, and merge. There are three main automations, plus a separate path for CompX v2.5.
Daily sweep
The first automation runs every day. It sweeps five active projects — Amarok, Canix402, Brownie Bot, Ghillie Bot, and Mallow — reads the development checklist files in each repo, and creates up to ten Linear tasks across those repositories. The checklists are the source of truth for what "next" means in each codebase, and the bot's job is to turn open checklist items into concrete, assignable work without inventing scope.
A human still decides what runs: we manually assign Cursor to those tasks in Linear to kick off the cloud agents. Each repo has its own Cursor environment, and agents cut branches from dev, make their changes, and open pull requests back into dev when they are done. That branching rule is in every ticket because review and merge happen on dev first, and main stays a deliberate promotion.
CompX outside the daily bot
CompX v2.5 is handled separately, because a roadmap is a different kind of work to the next checkbox in Amarok. We took the roadmap, split it into concrete tasks with Grok, and created those tasks on Linear outside the daily checklist sweep, which gives us room for sequencing, dependencies, and plans that are fully fledged before an agent starts coding.
From there the machinery is the same, with more human front-loading. We take five to ten CompX tickets at a time, turn each into a detailed implementation plan, then assign Cursor in Linear. That's how the website positioning work has been moving: agents-first homepage and nav, clAMM unroute, governance explainer, mock stake card — planned by humans, executed by cloud agents, reviewed by humans.
Custom bug bot
The second automation is a custom version of Cursor's bug bot. It reviews new pull requests and advises fixes, changes, or approval, which is another set of eyes on the diff before a human lands the work. All PR merging is still manual, and that's the point: agents can open the PRs, but they don't merge to production.
Weekly dependency review
The third automation is still a work in progress. For now it runs against Amarok once a week: inspect npm dependencies, recommend upgrades, and leave a review trail we can act on deliberately. The first runs have been review-only, without drive-by lockfile edits, while we learn what "recommended" means across majors, security advisories, and Node engine floors. We plan to expand the same pattern across the other repos eventually.
Mental load, and why we still check everything locally
Sending cloud agents into Linear tasks feels great but it also creates a real operational cost. Working across Cursor, Linear, and GitHub is a lot of surface area — tickets multiply, PRs multiply, environments differ by repo, and status drifts if you aren't careful — and it can get messy. The best way we've found to handle that is thorough final PR approval, taken slowly, including checking changes locally for issues and discrepancies the review UI will not show you.
We're lucky that these codebases carry a lot of unit and integration tests. They take unknowns out of agent-authored diffs, which doesn't replace reading the change, but it does make reading the change possible at the pace we're trying to ship. We're optimistic about this, with guardrails, and we're taking it in baby steps.
What's next
We're excited about this way of developing because it cuts some of the latency between a clear plan and a reviewable PR, even though it doesn't remove the need for judgment. CompX v2.5 surface work is already moving through that loop, governance staking and payouts are next, and epoch details, contracts, and claim flows still come before the first live vote.
We're also planning a new e-commerce platform on the same system — checklists, Linear, cloud agents, human merge — with the same preference for small steps over a theatrical rewrite.
Two weeks ago we promised a roadmap by the 15th and we published it. Then we started shipping against it with a delivery loop that's increased how much we can get through in a week, and we're looking forward to seeing where that takes the next stretch of work.