Your first AGELAIOS module in one hour

Extending a mission system should not begin with weeks of reverse engineering. A development team needs a clear contract, a repeatable toolchain and a safe environment in which to prove that its code behaves as intended.

AGELAIOS is designed around that principle. Its module workflow takes a developer from a generated project to a signed package running on an emulated node through eight explicit stages. Each stage produces evidence that can be inspected before the next one begins.

The one-hour target in this article is a design objective for that guided workflow, not a published benchmark. A formal timing protocol has not yet been defined and repeated, so we do not present the target as measured performance. The process can, however, be run without dedicated hardware. Teams can reproduce it, time it and assess the developer experience for themselves.

This guide follows the complete path with a minimal hello-track module, then explains the two decisions that matter most in production: the module contract and the isolation profile.

What you need before you start

The exercise requires three elements:

1. A cloned and verified AGELAIOS reference repository, using the procedure described in the sovereign instance guide.
2. The agelaios command-line tool built from that repository.
3. An emulated node. The platform can be emulated on x86-64 and ARM64, so no target computer is required for this workflow.

The command outputs described below show the expected form. The repository documentation remains the authoritative reference. The example uses Rust to create a small module that publishes a demonstration track to the node’s common operational picture. The generated workflow follows the same sequence for other languages supported by the template.

Eight controlled steps from idea to running module

1. Start from a valid project

agelaios new hello-track --lang rust --isolation wasi

agelaios new generates more than an empty directory. It creates a pre-filled module.yaml manifest, a gRPC service skeleton, an example test and the build configuration for the selected target.

The template is intended to compile and pass its tests before the developer changes it. This matters because the first engineering task is not to reconstruct the platform’s expectations. It is to implement useful behaviour inside an already valid structure.

2. Validate the declaration

agelaios lint

The manifest defines the module’s identity, requested capabilities and referenced interfaces. agelaios lint checks those declarations against the module contract schema.

An invalid identity, an unknown capability or a missing interface stops the workflow here, before compilation. Early rejection shortens the feedback loop and gives reviewers a precise rule to investigate instead of leaving the issue to surface during deployment.

3. Produce the isolated artifact

agelaios build --target wasm32-wasi

The build command compiles the module for its selected isolation target. In this example, the expected result is a single hello-track.wasm artifact and its digest.

For a WASI module, the same artifact can be used on x86-64 and ARM64 nodes. That portability reduces the number of architecture-specific packages a team must build, distribute and verify.

4. Test under representative restrictions

agelaios test

Local tests run in the same type of sandbox used by the node, with the same capability restrictions. A module that attempts to open an undeclared file, socket or clock should therefore fail during local testing rather than after installation.

The objective is straightforward: reduce the gap between development and execution. A green result does not replace the wider verification required for a production module, but it provides relevant evidence early in the process.

5. Create the publisher key

agelaios keygen --algo ml-dsa-65 --out ./keys/publisher

This command creates an ML-DSA-65 key pair based on FIPS 204. The private key remains local and is not sent to the repository or to Penrose Tactical.

A local key is sufficient for this exercise. Publishing to an operational fleet requires the key to be enrolled in the instance’s public key infrastructure and governed according to the operator’s policy.

6. Bind identity to content

agelaios sign --key ./keys/publisher --artifact out/hello-track.wasm

Signing produces a detached signature that covers the artifact and its manifest. This is the trust decision at the centre of the workflow.

An AGELAIOS node rejects a module unless its signature chains to a publisher key approved by that instance’s module store. Code cannot become trusted merely because it compiles or because someone can transfer it to a node.

7. Create the distribution unit

agelaios pack --out hello-track-0.1.0.ocm

The pack command combines the artifact, manifest and signature into a module archive. This archive is the distribution unit accepted by the module store and carried through the instance’s TUF repository.

Keeping these elements together makes the object submitted for approval the same object delivered for installation. It also gives the supply chain a stable unit to identify, sign and audit.

8. Install on an emulated node

agelaios emu up --profile node-x86_64
agelaios install hello-track-0.1.0.ocm --target emu

The emulated node verifies the signature, compares the requested capabilities with its local policy, loads the module into its sandbox and registers it in the local catalogue.

The expected result is an active module whose interfaces are visible from the node’s common operational picture in demonstration mode. At this point, the workflow has produced eight inspectable outcomes: a project tree, a lint verdict, an artifact, test results, a key pair, a signature, an archive and a running module.

That chain of evidence is more valuable than speed alone. It gives developers a short route to a result while preserving the controls that operators need.

Failure is part of the workflow

A credible toolchain must show how it fails, not only how it succeeds. The AGELAIOS workflow is designed to reject problems at the stage where they can be understood and corrected.

If the manifest is invalid, linting identifies the field and the violated rule before any build takes place. An unsupported capability is therefore treated as a contract issue, not discovered as an installation surprise.

If a test fails, the workflow stops before signing and packaging. Because the local test sandbox applies the node’s capability restrictions, undeclared access should fail where the developer can diagnose it.

If a signature is invalid, the emulated node refuses the archive and records the reason. Typical causes include an untrusted key, an artifact changed after signing or a manifest that no longer matches. The emulator does not provide a shortcut that forces an unverified module into the trusted path. The tutorial exercises the same trust principle expected on an operational fleet.

A contract that makes privileges reviewable

Every AGELAIOS module is defined by a declarative manifest with three central sections:

identity:
  name: hello-track
  version: 0.1.0
  publisher: example-ltd
capabilities:
  network: [mesh.tracks.publish]
  storage: [state.local]
interfaces:
  - grpc: agelaios.tracks.v1.TrackSource

The identity section names the module, its version and its publisher. Capabilities state what the module requests from the platform, including network, storage and hardware access. Interfaces identify the services it exposes or consumes.

Execution interfaces use gRPC contracts generated from a single typed, versioned definition [1]. An interface such as agelaios.tracks.v1 remains explicit in the manifest. When a contract evolves, a new version can be introduced without silently changing the one on which existing modules depend.

The commercial value of this model is practical. A reviewer can understand the requested privileges by reading the manifest. An instance operator can apply an approval policy to the same document. Developers can see the integration boundary before writing the implementation.

Nothing undeclared is assumed. Access absent from the manifest is refused at runtime, and behaviour absent from the gRPC contract is not part of the inter-module interface. This follows the same broad principle used by standardised container specifications, where runtime configuration is represented by an explicit, inspectable document [6].

Choose isolation according to the workload

Isolation is selected when the project is generated. AGELAIOS exposes three profiles because performance, compatibility and containment do not have one universal optimum.

Native execution for tightly controlled platform code

The native profile runs a module as a confined process using Linux mechanisms such as namespaces, cgroups and seccomp. It offers direct system access and the lowest isolation boundary of the three profiles.

That trade-off makes it appropriate for platform modules and workloads that need hardware or real-time access. It also demands the highest degree of trust. Native modules are reserved for platform components or code accepted through the instance operator’s full security review.

MicroVMs for system-level dependencies

The microVM profile runs the module inside a minimal virtual machine, following the lightweight virtualisation model demonstrated by Firecracker [3]. The module gains a guest kernel and can carry system dependencies that do not fit naturally inside WASI.

The stronger boundary has a cost. Each microVM requires more memory than the other profiles. It is therefore a deliberate choice for workloads that need operating-system compatibility or a hardware-virtualisation boundary, not a default applied without measurement.

WASI for portable, capability-based modules

The WebAssembly/WASI profile compiles the module to WebAssembly and runs it in a WASI-compatible runtime [2][4]. Files, sockets and other resources are exposed through explicit capabilities. The sandbox can therefore enforce the same intent expressed in the manifest.

WASI also offers architecture portability. One module artifact can serve different node architectures, provided the module and its dependencies are compatible with the selected WASI target. The WebAssembly Component Model adds typed interfaces at the language boundary [5].

This tutorial selects WASI because it is the recommended default for third-party data-processing modules such as connectors, fusion functions and calculations. A team should choose a microVM when an existing software stack needs its own system dependencies. Native execution is appropriate when platform-level hardware or real-time requirements justify direct access and the corresponding security review.

The selected profile is recorded in the manifest and module store. Changing it creates a new version that must be assessed and approved in its own right.

Turn a successful prototype into an approved capability

The emulated node is the end of this exercise, not the end of the engineering process. An operational module must still pass the assurance, integration and approval procedures defined by the target instance.

The workflow provides a useful starting point for that conversation. The module already has an explicit contract, a reproducible artifact, local test evidence, a publisher signature and a declared isolation boundary. Those controls do not guarantee operational suitability, but they make the module easier to evaluate and safer to introduce.

Teams can contribute a useful, signed and well-isolated module to the project’s community catalogue, propose it to an instance operator or work with Penrose Tactical on the integration path. The strongest reason to adopt a modular platform is not that every extension is effortless. It is that extension becomes structured, reviewable and repeatable.

Run the workflow with your own use case. Measure the time, inspect every gate and decide whether the resulting evidence meets your engineering standard.

Sources

1. gRPC Authors, “Introduction to gRPC”, 2024.
2. WASI Subgroup, W3C WebAssembly Community Group, “WASI, the WebAssembly System Interface”, 2024.
3. Amazon Web Services, “Firecracker, secure and fast microVMs for serverless computing”, 2024.
4. Bytecode Alliance, “Wasmtime Documentation”, 2024.
5. Bytecode Alliance, “The WebAssembly Component Model”, 2024.
6. Open Container Initiative, “OCI Runtime Specification”, 2024.