1. Why Architecture Awareness Matters
Previous versions of Blueprint operated on a clean-slate assumption — given a prompt, they would design an architecture as if building from zero. This works for greenfield projects, but the majority of engineering work happens in existing systems with established patterns, running services, and accumulated technical decisions that cannot be ignored.
Blueprint 1.7 introduces architecture-aware generation: before producing any plan, it constructs a model of your current system state — running services, dependency versions, infrastructure topology, deployment targets — and uses this context to generate plans that fit within your existing architecture rather than contradicting it.
The result is a planning system that behaves like a senior engineer who has been on your team for six months — one who knows the codebase, understands the deployment setup, and makes recommendations that account for technical debt and migration paths rather than idealized abstractions.
2. Runtime Context Extraction
Architecture awareness begins with runtime context extraction — a pre-generation phase where Blueprint 1.7 analyzes your repository to build a structured model of the current system.
This model includes:
- Service topology: What services exist, how they communicate (REST, gRPC, message queues, event buses), and their current deployment targets.
- Dependency graph: Runtime dependencies between services, shared libraries, and external integrations — mapped from import statements, configuration files, and IaC definitions.
- Infrastructure state: Cloud resources defined in infrastructure-as-code — databases, caches, queues, networking, and access boundaries.
- Pattern recognition: Established architectural patterns in the codebase (repository pattern, event sourcing, CQRS, microservices vs monolith) that new code should follow for consistency.
- Constraint inheritance: Existing technology choices that constrain future decisions — if you're running PostgreSQL 14, Blueprint won't suggest features that require PostgreSQL 16 without flagging the upgrade requirement.
Example - Context Extraction Output
Detected: Node.js 18 monorepo (Turborepo), 3 services (api-gateway, auth-service, payment-service), PostgreSQL 14.2, Redis 7.0, deployed on a managed container service, infrastructure-as-code managed, event-driven communication via message queues between services. Patterns: Repository pattern for data access, JWT-based auth with refresh token rotation, OpenAPI-first API design.
3. Incremental Planning: Extending Existing Systems
The most significant behavioral change in Blueprint 1.7 is incremental planning — the default mode now assumes you are extending an existing system rather than building from scratch.
When you prompt Blueprint 1.7 with "Add a notification service that sends emails and push notifications when orders ship," it does not design a standalone notification system in isolation. Instead, it:
- Identifies the event source: Locates the order service and its existing event emission patterns (message queues, database triggers, webhook dispatches).
- Selects the integration point: Determines whether to consume existing queue events or propose a new event channel, based on current queue topology and message schemas.
- Inherits architectural patterns: If existing services use the repository pattern with dependency injection, the notification service is designed with the same patterns for codebase consistency.
- Validates infrastructure fit: Checks whether the notification service can deploy to the same container cluster or requires additional infrastructure (e.g., an email service for sending, a push notification service).
- Produces migration-safe output: Generates infrastructure-as-code additions that extend the existing state file rather than creating parallel infrastructure that could conflict.
4. Benchmark Results: Blueprint 1.7 vs Blueprint 1.0
We evaluated Blueprint 1.7 against Blueprint 1.0 across 50 real-world planning tasks submitted by Agnixa users (anonymized and used with consent). Tasks ranged from simple feature additions to complex multi-service architecture redesigns.
| Metric | Blueprint 1.0 | Blueprint 1.7 | Improvement |
|---|---|---|---|
| Plans requiring zero manual correction | 34% | 71% | +37pp |
| Correct dependency ordering | 78% | 96% | +18pp |
| Infrastructure compatibility (no conflicts) | 52% | 89% | +37pp |
| Pattern consistency with existing codebase | 41% | 87% | +46pp |
| Average generation time | 45s | 28s | -38% |
The largest improvement is in pattern consistency (+46pp) — directly attributable to the runtime context extraction phase. Blueprint 1.0 generated architecturally valid but stylistically inconsistent code; Blueprint 1.7 inherits the established conventions and produces output that looks like it was written by someone already on the team.
5. Availability and Access
Blueprint 1.7 is available to all Agnixa users — free, basic, pro, and startup plans — starting June 15, 2026. No migration is required; Blueprint 1.7 replaces the previous generation engine automatically when selected as your active brain.
For teams already using Blueprint, existing session history and project context carry forward. Blueprint 1.7 will re-index your repository on first use to build the runtime context model, which typically completes in under 30 seconds for repositories under 100K lines of code.