Organizing the Backlog: From Mega Sprint to Structured Roadmap

Blog Entry

Yesterday we shipped. Today we organized.

After a 3 week-long mega sprint that took Arachne from proof-of-concept to functioning beta, we had the kind of problem every early-stage project wants: a huge list of things that work, and an even longer list of things we want to build next. The backlog was living in Slack threads, PR comments, and people’s heads. That had to change.

The Audit

We started by closing 17 issues that the mega sprint had already resolved. CLI auth, knowledge base management, agent deployments, embedding agents, the admin dashboard, the entire beta launch epic — all verified and closed. It felt good to mark that ground as taken.

Then the team did a thorough audit of the codebase. Trinity walked through every page in the Portal and Dashboard, cataloging inconsistencies: checkboxes that should be toggles, blue buttons next to indigo buttons, window.confirm() calls that should be proper modals. Tank and the Architect traced every raw SQL query and mapped out which ones could be eliminated and which needed to stay (analytics and vector search earn their raw SQL). Mouse designed a 14-step smoke test that would exercise the full agent lifecycle end-to-end. Cypher flagged the EntityManager forking issue — a subtle multi-tenancy safety problem where concurrent requests could theoretically leak data across tenant boundaries.

Four Phases

We organized everything into four phases, each with its own label and priority tier:

Phase 1: Beta Hardening is about making what we have production-worthy. The top priorities are UX consistency (Trinity’s audit), the EntityManager forking fix (security), completing the multi-provider epic (Stories 3-7), API key expiry and rotation, and bridging the Provider entity system to the actual proxy adapters. We also need a proper smoke test suite and to start eliminating unnecessary Knex usage.

Phase 2: Production Ready adds the things enterprise users will expect before they commit: audit logging, more provider adapters (Claude, Gemini), granular RBAC, cost dashboards, and an agent playground for testing without leaving the Portal.

Phase 3: Differentiation is where Arachne stops being “an AI gateway” and becomes the thing you can’t get elsewhere. The headline feature is arachne eval — define evaluation suites in YAML, run them against agent versions, gate deployments on pass rates. This is the killer feature. Hybrid search for RAG, model routing with automatic failover, and advanced conversation memory strategies round it out.

Phase 4: Ecosystem is the long game. Agent marketplace, plugin system, enterprise SSO, data residency, and open spec governance. These are the features that turn a tool into a platform.

The Numbers

We created 25 new issues across the four phases. Nine are Phase 1 (beta hardening), six are Phase 2 (production ready), five are Phase 3 (differentiation), and five are Phase 4 (ecosystem). Each one has acceptance criteria, file references where applicable, and cross-references to existing issues and epics.

The Phase 1 P1 issues — the ones the team will pick up first — are:

1. UX consistency pass (Trinity’s audit)
2. EntityManager per-request forking (security fix)
3. Multi-provider Stories 3-7
4. API key expiry and rotation
5. Provider entity-to-adapter bridge
6. Round-trip agent lifecycle smoke test

What This Means for Beta Users

If you are using Arachne today, the immediate focus is stability and consistency. The gateway works. The CLI works. The Portal works. Now we are making all of it feel like one product instead of several features bolted together.

The backlog is public. You can see every issue, every priority label, every phase tag. If something matters to you, comment on it. If something is missing, open an issue. We built Arachne in the open and we intend to keep it that way.

Next up: Sprint 1 starts Monday. Trinity takes point on UX. Cypher tackles the EntityManager fork. Tank continues the provider epic. Mouse builds the smoke test. We ship again Friday.