--- title: "Product roadmap" description: "Current product stage, next milestones and the evidence needed for customer readiness." canonical: "https://agenttwin.si/docs/roadmap/" --- # Product roadmap Current product stage, next milestones and the evidence needed for customer readiness. Updated October 19, 2026. AgentTwin is an **engineering alpha entering pilot validation**. The next milestone is one real application workflow that a team can install, reproduce, fix and protect on future pull requests. ## Available foundations The source includes guided repository discovery and reviewed sharing, reusable test worlds, linked scenarios, explicit outcome checks, replay and protected regression tooling. Stripe and Slack plus thirteen additional provider adapters implement bounded subsets; detecting a provider does not establish compatibility with its full API. Four fault classes exist: timeout after a write, dropped responses, server errors and duplicate writes. Seeded selection and delays, captured-source replay, unchanged-check patch verification and bounded fault shrinking are implemented. These do not control arbitrary operating-system scheduling or guarantee deterministic model responses. The dashboard, account-scoped sync, Google/GitHub/OIDC sign-in code and organization-realm selection are implemented. Live release and enterprise acceptance are verified separately from source and local tests. ## 1. Close the release gap Version `0.3.8` is published on npm, with CLI/MCP reporting aligned and registry integrity matching the tested tarball. Verify the intended website/API rollout and live authentication acceptance. **Done when:** a clean installation of `npx agenttwin init` pairs with the right workspace and shares reviewed discovery; installed/deployed revisions and real authentication acceptance are recorded. ## 2. Run one real application workflow Confirm a pilot workflow's trigger, invocation, runtime, exact service operations and persisted state. Run the actual application revision with test credentials and seeded records. Customer requirements must define the expected outcome and forbidden side effects. **Done when:** the supported workflow runs end to end, its coverage is visible, and unsupported behavior produces an incomplete result. ## 3. Prove provider correctness Expand adapters around the pilot's required operations. Compare behavior with official SDKs and authorized test accounts, including authentication, pagination, mutations, errors, retries, reset and webhooks where needed. **Done when:** each required operation has a versioned contract, conformance evidence and explicit limitations. Adapter count alone is not the acceptance criterion. ## 4. Turn a real failure into a protected regression Reproduce a meaningful failure, connect evidence to the failing operation, patch application source and rerun unchanged checks. Save the scenario and install a required pull-request check using a trusted grading baseline. **Done when:** the original code fails, the fix passes, a deliberately reintroduced defect fails, and candidate changes cannot weaken the grading checks. Protected browser/background and database-backed execution still need broader runner support. ## 5. Earn repeated pilot use Make onboarding and evidence understandable, measure setup effort and false positives, and observe teams using the checks across releases. Broaden runtime and provider coverage from actual workflow needs. **Done when:** a pilot can show measured setup time, useful defects, dependable regression results and repeat use. Synthetic demonstrations and engineering tests do not establish adoption or willingness to pay. ## Enterprise and scaling gates Implement and verify required team roles, tenant SSO enforcement, audit evidence, retention/deletion controls, monitoring and backup/restore before promising enterprise readiness. Move the single-instance store and scheduler to a suitable distributed design before scaling replicas. Any security controls required by the first pilot take priority before granting that pilot access. Shared agent memory helps the development team coordinate; it does not replace provider conformance, customer outcome checks or operational evidence. Roadmap order is a priority sequence, not a delivery-date commitment. ## First private application slice On October 19, a local test of the actual calendar-reading function reproduced missed appointments on short paginated responses. The captured original fails; an application-only patch passes unchanged checks; replay still reproduces the original failure. The regression and private source stay local. This proves a calendar-read slice, with a controlled transport returning short pages. It does not establish full scheduling, Bun/SQL execution, live Google conformance or a protected customer PR check. The local protected Docker check also rejects the original calendar bundle and accepts the fixed bundle with unchanged trusted checks, even when the candidate attempts to weaken its own regression definition. Private-repository build and required-check installation remain open. Release candidate `f9338a5` passed 361 CLI tests, 17 web tests, the website build and fresh tarball installation. npm published `0.3.8`, and public registry integrity matches the tested tarball. Production health is reachable, but email verification is reported disabled and full live sign-in acceptance remains open. These checks do not close P0 or establish complete pilot readiness.