# Semryn product strategy and AIR technical roadmap Status: proposed commercial direction. The compiler and binary graph engine are working prototypes; repository indexing, repository patches and integrations with external coding agents are future work. ## Product thesis Semryn is the public product/platform brand for semantic software infrastructure between AI coding agents and existing repositories. It is powered by **AIR — AI Intermediate Representation**, the underlying semantic representation and compiler technology. The initial commercial product is the **Semryn Context Engine**; AIR remains the technical name, not an alternative company name. The commercial message is: > Make AI coding agents significantly cheaper, faster and safer on real software > repositories. This is a value proposition to validate through measured pilots, not a claim already established by the prototype. Selling a new programming language is not the primary business. Customers should keep their applications in PHP, TypeScript, Java, Rust, Python, C# and other existing languages. They should not need to rewrite an application, replace its runtime or adopt AIR source files. ```text Codex ──────┐ Claude Code ├──→ Semryn ──→ AIR semantic graph ──→ existing repository Gemini ─────┤ custom AI ──┘ ``` These are intended integration targets, not integrations currently delivered. Semryn should remain independent of a particular agent vendor or model. The engine owns semantic indexing, context selection, patch validation and source mapping; the agent owns task interpretation and proposed changes. ## Initial product: Semryn Context Engine ```text Existing repository and revision ↓ Language adapters and incremental semantic indexing ↓ AIR repository semantic graph ↓ Task-specific context extraction ↓ AI coding agent ↓ AIR semantic patch ↓ Revision, structure, language and task validation ↓ Minimal source-code change in the existing language ``` Today an agent may repeatedly find files, grep, read files, search references, read tests and inspect surrounding code just to establish where a change belongs. The engine should retain that structural knowledge and return a bounded task context: relevant symbols, implementations, callers, dependencies, tests, constraints and unresolved edges, with source references and snapshot identity. It should support further targeted queries when the first context is insufficient. The first useful product can be read-only semantic context. Validated mutation is the subsequent product capability; it should not block an indexing pilot. The context engine may accompany an agent's existing search tools during trials, so missing coverage does not prevent ordinary repository work. The target editing workflow addresses stable semantic entities and expected repository revisions. An agent should request a change to a symbol or dependency, not regenerate an entire file. Language adapters translate accepted patches into small source edits that preserve unaffected formatting, comments and behavior. Existing source remains the customer-facing application representation and the reviewable Git diff. ## Customer and adoption path The initial pilot customer is a software team already using coding agents on an existing repository, with repeatable tasks and meaningful test/build checks. Prioritize repositories where repeated navigation, oversized context and repair cycles can be measured. Choose the first language adapter from actual pilot repositories; support for every listed language is a long-term direction. A low-friction onboarding path should be: 1. Connect a repository at a fixed revision using a local engine or approved deployment. 2. Index a supported subset and disclose unsupported or uncertain semantics. 3. Connect one agent through an adapter; keep existing search tools available. 4. Run read-only task context alongside the existing workflow. 5. Enable proposed semantic patches after context quality and source mappings have been demonstrated. 6. Produce normal source diffs, validation results and reviewable changes using the team's existing build, test and approval process. There is no required application migration and no requirement to learn an AIR textual programming language. AIR graphs are an internal machine-oriented layer. ## Product and open technology Semryn is the product/platform; AIR is the semantic representation and compiler technology underneath it. An open AIR specification/compiler foundation remains a proposed direction, not a finalized licensing decision. No open-source license is asserted by this document; the current repository has no license declaration. Compiler modules, graph formats and CLI names remain AIR-related. Semryn-branded context and agent infrastructure should be evaluated as commercial products. ## What can be sold The paid product should be an engine and integration layer that saves agent work, rather than access to a language syntax. Candidate paid capabilities are: - Incremental semantic indexing and reusable repository knowledge. - Task-specific context extraction and dependency-aware navigation. - Agent adapters and controlled semantic patch execution. - Change validation, affected-test selection and auditable result receipts. - Team policy, access boundaries and deployment options when customer demand justifies them. Start with a narrow paid pilot that measures benefit on real tasks. Evaluate packaging around connected workspaces or active agent usage, with explicit engine resource costs. Pricing, hosted deployment and enterprise controls are product decisions to validate with customers; they are not implemented here. Do not promise positive economics before accounting for indexing, inference, validation and integration overhead. ## Value proposition and evidence The expected gains are less context, fewer tokens and tool calls, fewer failed attempts and repair cycles, safer changes, better dependency understanding and lower inference cost. Every claim needs an observable definition. | Outcome | Pilot measurement | | --- | --- | | Less context | Task-relevant context bytes and model-visible input tokens; context coverage and relevance | | Fewer tokens | Total input/output tokens, including discovery, retries, repairs and verification | | Fewer tool calls | Calls per accepted task, including indexing/context queries, fallbacks and validation | | Fewer failed attempts | Rejected patches and unsuccessful task completions per attempted task | | Fewer repair cycles | Edit/check/repair iterations before acceptance | | Safer changes | Escaped regressions, failed checks, unintended changed scope and stale-update rejection | | Better dependency understanding | Relevant callers/dependencies/tests found against a curated task reference set | | Lower inference cost | Actual model charges per accepted task, including cached-token pricing where applicable | | Faster delivery | End-to-end elapsed time per accepted task, not just graph operation latency | | Sustainable economics | Inference plus engine/indexing/validation/hosting costs per accepted task | Compare the same task set with and without Semryn using the same agent, model, repository revision, success criteria and tool permissions. Include small edits, cross-file changes, dependency-sensitive changes and tasks requiring repair. Use repeated runs and report distributions, success rates and absolute costs. Account for cold indexing and amortized warm indexing separately. Record failures and cases where Semryn increases work, not only successful demonstrations. Define task acceptance before runs using host-owned checks and human review as appropriate. A cheaper incorrect patch is not a saving. Decide pilot go/no-go thresholds with the customer before evaluating results; do not invent a universal speed multiplier or token-reduction percentage. Binary size and in-process patch latency are engineering metrics. They do not by themselves establish fewer model tokens or lower inference cost. Agent adapters must expose useful compact context in a form the agent can consume; raw binary transport does not automatically change a model's tokenizer. ## Architecture implications ### Repository semantics and source mappings The current compiler models small native and static-web programs using one ordered SSA block. It is not yet a representation of arbitrary existing software. A repository graph needs files, modules, symbols, declarations, reference edges, source spans, language identity and analysis provenance. Future richer control flow and effects should be introduced when a concrete repository task needs them. Repository adapters must preserve the original source as the authoritative input at a specific revision and derive graph views from it. Binary graphs are internal indexed representations; they must not silently discard information needed to produce faithful source changes. Keep compiler IR and repository views explicitly separated where their invariants differ, while sharing suitable type, schema, revision and validation mechanisms. Use snapshot-bound entity identities and source-content preconditions. Define how identities survive edits before supporting cross-revision semantic patches. Avoid treating a source location alone as stable identity. Unsupported constructs, dynamic dispatch and external dependencies must be explicit unknowns, not invented certainty. Prefer correct partial coverage with clear fallback over claiming a complete cross-language graph. ### Context as a product API Context extraction should select entities and dependencies for a task within a specified budget. Return why an entity is relevant, its source anchor, freshness and coverage limits. Support bounded expansion to callers, definitions and tests. Cache semantic work across tasks and invalidate affected nodes when source changes. A small context is useful only if it retains the information needed for the task. ### Patches and validation The current engine's attribute edits apply to its own binary graphs; they do not edit PHP, TypeScript or other repository source today. Future repository patches need language-specific admissible operations and explicit preconditions. Engine validation should precede source writes, and accepted edits should yield normal, minimal source diffs rather than rewriting unrelated files. Validation has several distinct layers: - Snapshot/revision checks prevent stale edits. - Graph/schema checks reject broken references and incompatible operations. - Language parser/type/build checks verify what the language tools can establish. - Existing tests and host-owned task contracts check specified behavior. - Repository policy and review gates govern accepted change scope. Recheck changes against actual source after lowering, and discard a proposed change if its preconditions no longer hold. Do not equate structural validity with correct business logic. An agent can still misunderstand a task; the goal is fewer accepted errors and clearer evidence, not a claim that AI cannot err. Capabilities and access controls should constrain mutations before enabling multi-user or remote workflows. No push, merge or deployment authority is implied by a semantic patch. ### Integration and economics Keep the engine's binary graph and control representation independent of agent vendors. Adapters bridge each agent's supported tool interface; requiring agents to move their entire execution environment into AIR would hinder adoption. Instrumentation must attribute context, tool, inference and validation costs to a task. Incremental indexing and targeted queries should earn their place through those measurements, not through lower-level performance claims alone. ## Technical roadmap aligned with the product These are capability milestones, not release dates or promises. Select a narrow language/task scope and establish acceptance criteria at each stage. | Milestone | Deliverable | Exit evidence | | --- | --- | --- | | 0 — AIR semantic foundation | Binary graphs, typed construction, revisioned edits, native/HTML lowering and host-output checks | Current tests and executable demonstrations; no claim of repository integration | | 1 — Semryn repository intelligence: read-only context pilot | One language adapter, snapshot-bound symbols/references/source anchors, bounded task context, one agent adapter and task instrumentation | Context correctness/coverage on reference tasks and measured cold/warm overhead against the agent's existing workflow | | 2 — Semryn agent infrastructure: controlled patch pilot | A narrow semantic edit set, source preconditions, minimal source lowering, parser/build/test checks and ordinary Git diffs | Faithful source changes, stale-patch rejection, preserved unaffected source and accepted end-to-end tasks | | 3 — Commercial evidence pilot | Repeatable task benchmark and real team trials using context plus validated patches | Measured accepted-task quality, total tokens/tool calls/repair cycles, elapsed time and total cost; customer-defined go/no-go thresholds | | 4 — Productization | Reliable indexing lifecycle, policies, receipts, integration packaging and deployment support demanded by pilot customers | Operational reliability and a supported paid workflow without application rewrites | | 5 — Broader language and agent coverage | Additional adapters chosen by demand; measured shared semantics and explicit language-specific gaps | Per-adapter task acceptance and economics, rather than an unsupported universal-language claim | The **single next technical milestone** is milestone 1: a read-only repository context pilot for one existing language and one agent integration. Do not first expand the prototype into a general-purpose language or require a rewritten application to demonstrate customer value. The native/web compiler remains a useful research track for graph validation, backend separation and controlled construction. Arithmetic, Bool, control flow, functions, regions, richer effects, capabilities and contracts may contribute when pilot needs justify them. MLIR/LLVM/WASM/GPU backends, a new VM, custom tokenization and a broad AIR application ecosystem are not prerequisites for the initial commercial product. A static-web demo proves a backend path; it does not prove lower agent cost on real repositories. ## Present implementation boundary Implemented now: - Canonical binary native/web graph serialization and typed SSA structures. - Central operation schemas, explicit effects and deterministic validation. - C-to-native and static HTML backends. - Persistent local binary control, typed construction slots and atomic attribute edits with revision checks. - Host-owned checks for demonstrated native stdout/exit behavior and selected static-web facts, with binary verification receipts. Not implemented now: indexing an existing repository, task context extraction, source-language adapters, source-preserving semantic patches, Codex/Claude/Gemini integration, repository policy enforcement, remote service authorization or a paid product. Current benchmark results concern local prototype operations and cannot support a commercial claim of reduced agent inference cost. This strategy changes the direction of future work. It does not require a change to the current compiler implementation.