Aion adds governed model selection to its ICP AI architecture

On October 19, 2026, Alfonso, founder of Teves Consulting, said that Aion, his AI companion built on the Internet Computer, had finished its "Governed Selection and Orchestration" milestone, the last of four foundational architecture steps. If you build AI agents on ICP, you can use the same layering (identity, memory and approvals in canisters, a swappable model behind them), but Aion is closed source, so there is no code to reuse.

What Aion shipped on October 19

The new post says Aion now treats six questions separately before any capability acts:

• whether a capability is suitable for the task;
• whether it is permitted under the applicable boundaries;
• whether required approval exists;
• whether it should actually be selected;
• whether execution is separately authorized;
• whether the result can be verified.

The post also describes "bounded orchestration": several model calls can work on one problem with distinct responsibilities, controlled context transfer and final human authority. The author says this is not an autonomous agent system. If no option is clearly right, because evidence is missing, approval is unresolved, or two choices are equally reasonable, the system should select nothing and keep the uncertainty visible.

According to the author, this milestone completes four steps: Assurance and Verifiable Execution, Bounded Intelligence, Approval-Bounded Workflows, and Governed Selection and Orchestration. The next focus is "local-first, resilient and continuous intelligence", with less dependence on external providers.

The thread has been running since July. Here are the posts in order:

Who this affects and why it matters

The thread matters most to teams that run AI agents in canisters and call outside models. In the July 16 post, the author says the external model now has one narrow job: "Generate the next piece of text." Identity, continuity, memory ranking, grounding and provider policy stay in the application. The July 26 post explains the reason: the model "does not determine" identity, memory, ranking, grounding or provider policy. If a provider changes or disappears, the user's history and permissions are not lost.

Today this split maps directly onto two official ICP options. The ICP developer docs describe an LLM canister (w36hm-eqaaa-aaaal-qr76a-cai) that runs inference on ICP nodes without API keys. The other option is HTTPS outcalls to commercial APIs. Aion routes between both, so its policy layer has to deal with the differences shown below (values from the ICP docs):

Aion's user memory is tied to Internet Identity principals. If your app does the same, read ICP's New Canonical URL Is an Identity and Trust Boundary before you change domains.

What to do now

Aion's code is not available, so use the pattern, not the implementation. These steps follow the layering described in the thread and use the official LLM canister docs:

1. Build the context inside the canister. Rank memory, select context and retrieve grounding sources in your own canister state. Send the model only the finished context.
2. Put provider choice behind one policy function. Keep the route (LLM canister or HTTPS outcall) as data the operator controls, so you can roll back without redeploying the logic.
3. Keep approval and execution separate. Store an approval for one specific action and target. Check it again just before execution, and never let a different model or route get around a recorded rejection.
4. Record consequential actions. Save what was requested, under which principal, which route answered and what happened.
5. Stay within the LLM canister limits. During the rollout the docs list a maximum of 10 messages per chat request, a maximum prompt size of 10 KiB, a maximum of 1000 output tokens, and no streaming. Trim history before each call.

For the on-chain route in Motoko, the docs give the dependency for the llm package version 2.1.0:

# mops.toml
[dependencies]
llm = "2.1.0"

Then run mops install and call the chat API from your actor:

import LLM "mo:llm";

persistent actor {
  public func chat(messages : [LLM.ChatMessage]) : async Text {
    let response = await LLM.chat(#Llama3_1_8B).withMessages(messages).send();
    switch (response.message.content) {
      case (?text) text;
      case null "";
    };
  };
};

The docs list ic-llm = "1.1.0" with ic-cdk = "0.17.1" as the Rust equivalent. The LLM canister is not available on a local replica, so the docs recommend a mock canister for local tests and icp deploy -e ic for real inference.

Caveats

Aion is not open source. Every architecture claim in the thread is self-reported, with no published code, test results or metrics. Two forum members replied that the posts and the project website looked AI-generated. The LLM canister is free during its initial rollout, and the docs say pricing will be announced before that period ends. Include that future cost in any routing policy that prefers the on-chain route.