Goals
Ikidna is being developed in two intentional phases. The near-term phase optimizes for immediate usage and value generation, while the longer-term phase optimizes for interoperability and broader adoption.
Primary Goal
Section titled “Primary Goal”The first and most important goal is to build a software-development flywheel: use Ikidna to accelerate software delivery so the system helps build the next version of itself.
Phase 1 is therefore intentionally focused on code-generation and software-delivery workflows. More general-purpose AI uses (for example chatops assistants and broader business automation) are explicitly deferred until this flywheel is working reliably.
Phase 1: Opinionated Prototype
Section titled “Phase 1: Opinionated Prototype”Build an initial working system that is tightly aligned to the current preferred stack and operating model.
See the current architecture
Intent
Section titled “Intent”- Move quickly from architecture to running software-development workflows.
- Establish a repeatable code-generation loop from issue -> implementation -> review -> feedback.
- Reduce integration complexity while core orchestration patterns are still being discovered.
- Validate high-value capabilities end-to-end (agent invocation, harness control, telemetry, and execution ledger flow).
- Use these validated workflows to accelerate delivery of Phase 2 prerequisites.
Tradeoff
Section titled “Tradeoff”The system is intentionally coupled to chosen technologies and intentionally narrow in use-case scope. This limits portability and breadth in the short term, but maximizes iteration speed, feedback quality, and progress toward Phase 2.
Phase 2: Generalized Integration Platform
Section titled “Phase 2: Generalized Integration Platform”Evolve Ikidna into a more generic orchestration layer that can integrate with multiple subsystems and interchangeable software choices. This requires decoupling systems and using adapters to allow for more general use cases.
Intent
Section titled “Intent”- Support multiple operational environments and runtime patterns.
- Enable adapters for alternate harnesses, models, storage, and surrounding control-plane systems.
- Preserve common orchestration semantics while allowing implementation swaps underneath.
- Expand beyond code-generation-first workflows into broader automation surfaces such as chatops and business-process automation.
Tradeoff
Section titled “Tradeoff”Generalization adds design and integration overhead, but it is the preferred long-term direction for scale, portability, and ecosystem fit.
Why Two Phases
Section titled “Why Two Phases”A tight initial coupling and narrow software-development focus are deliberate bootstrap strategies, not the final architecture target. Ikidna first proves a high-value delivery flywheel with a constrained stack, then progressively decouples via adapters and stable interfaces once the core execution model is validated.