Roadmap at AGIACC
From research to a deployable platform.
Start with one reproducible workflow. Establish its value. Extend the stack where evidence supports it.
The destination is a trustworthiness-native platform connecting application permissions, system execution and hardware protection, with measured resource costs. The first product milestone is the AGIACC Reference Platform and SDK. Its scope is deliberately bounded so that an external engineer can evaluate a complete workflow.
Our current foundation is published research and available artifacts. Product integration, releases and partner evaluations are planned. The horizons below are estimates from project kickoff, subject to resourcing and technical findings; work may overlap, and advancement depends on the stated evidence.
Delivery stages#
Research foundations
Published research and available artifacts in memory protection, sandbox orchestration, and AI systems efficiency.
Foundation to build on
- Selected founder research in memory protection, compiler optimization, sandbox orchestration and AI systems efficiency.
- Available paper and code artifacts, with their original authorship and institutional context preserved.
Evidence to carry forward
- Identify the artifacts relevant to the first workflow and record their versions, dependencies and reproduction status.
- Separate prior research results from properties still to be established by the integrated platform.
Next decisionChoose the first workload, supported host configuration and threat model.
Reference demonstration
Connect a defined threat model, existing hardware or emulation, runtime isolation, and explicit application permissions.
Planned deliverables
- One document-analysis workflow with approved inputs, a designated report output and an isolated tool.
- A prototype policy interface, one execution backend and tests for unrelated file access, outbound communication and timeouts.
- A separate native-memory fault example on supported hardware or emulation, with an explicit statement of coverage.
Evidence to advance
- The legitimate task completes; named unauthorized operations are rejected without prohibited side effects, confirmed by checks outside the tested workload.
- Configuration, trusted components, cleanup behavior and known gaps are recorded with repeatable instructions.
Next decisionConfirm that the chosen boundary is enforceable and worth packaging into a developer release.
Reference platform + SDK
Package developer examples, permission interfaces, fault reporting, and evaluation tooling.
Planned deliverables
- An installable reference environment and SDK/CLI for policy configuration, tool invocation and structured results.
- An evaluation kit with versioned workloads, boundary and fault cases, outcome checks and an exportable report.
- A documented deployment profile, integration guide and measured baseline for latency, memory and task completion.
Evidence to advance
- An external engineer reproduces the workflow using the release documentation and reports any required assistance.
- Permission checks, cancellation, reset and fault handling are tested; resource costs and unsupported properties are documented.
Next decisionSelect a partner workflow and agree the scope and acceptance criteria for an evaluation.
Partner evaluation
Adapt the platform to selected workflows and test paid evaluation and integration as the initial commercial offering.
Planned deliverables
- A bounded integration for a selected partner workload and deployment environment, with an agreed permission model.
- A joint evaluation report covering protection, useful task performance, reliability, operating cost and integration effort.
- A proposed support scope and a prioritized set of product requirements drawn from partner feedback.
Evidence to advance
- The evaluation addresses the agreed workflow criteria and makes remaining deployment limitations explicit.
- Evidence of user value and willingness to pay supports a decision on a repeatable offering; support effort is understood.
Next decisionDetermine which deployment profile, integration or performance improvement merits further investment.
Platform expansion and hardware co-design
Explore chip design, new devices and accelerator integration alongside system software, application frameworks and platform services, guided by deployment needs.
Planned deliverables
- Additional deployment profiles, framework integrations or platform services where earlier evaluations establish demand.
- Targeted ISA, processor, accelerator or new-device feasibility studies addressing a measured limitation of existing platforms.
- Hardware–software prototypes with appropriate compiler/runtime support and a verification and measurement plan.
Evidence to advance
- A proposed extension solves a demonstrated requirement and offers measurable benefit against a relevant baseline.
- Hardware work has suitable partners, resources and a credible validation path. Custom-chip delivery requires a further programme and separate gates.
Next decisionAdvance the validated product or hardware direction; defer extensions without sufficient evidence.
Three research tracks, one delivery programme#
Hardware research begins with the reference platform. Integration reveals protection gaps and overheads; research determines which improvements are worth carrying into the next release.
| Research track | Reference platform 0–6 months | Partner evaluation 6–12 months | Evidence-led expansion 12–24+ months |
|---|---|---|---|
| Hardware and new devices | Characterize supported mechanisms; run a native-component protection experiment on existing hardware or emulation. | Measure coverage, compatibility and cost on relevant devices; identify limits that matter to a deployment. | Investigate ISA, chip, accelerator or device changes when a validated requirement justifies co-design. |
| System software | Integrate one execution backend with policy mapping, lifecycle controls, failure reporting and a repeatable test runner. | Evaluate reliability, resource management and service connectors in selected partner environments. | Extend deployment profiles and optimize measured bottlenecks while preserving their required boundaries. |
| Application frameworks | Deliver a task-policy interface, SDK/CLI and a complete example application. | Adapt one partner workflow; assess developer effort, useful task quality and operational needs. | Develop reusable frameworks or platform services around demonstrated integration and support needs. |
The research agenda develops the trustworthiness and efficiency questions behind these tracks. Simulated hardware experiments will be identified separately from measurements on physical devices. Custom silicon requires a measured limitation of existing platforms, a credible integration path and appropriate partners and funding.
Evidence that governs each decision#
We will evaluate progress in the following order. A faster implementation advances only if it preserves the required boundaries and permitted behavior.
- Protection and containment: test named violations and fault classes against explicit boundaries and trusted-component assumptions.
- Task completion and failure handling: check legitimate results, prohibited side effects and the handling of denials, timeouts and faults.
- Reproduction and integration: record installation and integration effort, compatibility gaps and operational limitations.
- Resource cost: compare startup, task latency, peak memory and throughput against a recorded baseline, with repeated trials and variability. Energy requires suitable hardware measurements.
For partner evaluations, useful task quality and operating constraints will be agreed with the partner. Results will identify unresolved gaps and determine whether the next investment should improve protection, simplify integration, reduce overhead or change the target use case.
What seed funding is intended to unlock#
Seed resources would support three concrete outcomes: an integrated reference implementation, independently reproducible developer and evaluation packages, and initial customer evaluations. Engineering and measurement come first, alongside discovery of workflows where execution boundaries affect adoption.
The first commercial test is whether a team will pay for a bounded evaluation and integration. Evidence of repeatable demand, manageable support effort and acceptable operating cost would guide a supported platform offering. Deployment services and deeper hardware co-design remain later decisions with their own technical and commercial requirements.
Build the next stage with us#
We welcome teams with a specific workload to evaluate, researchers working across the hardware–software boundary, and investors interested in turning systems research into infrastructure. A useful starting point is one task, the resources it needs and the failure that must be prevented or contained.