Skip to content

Back to the catalog

LOGOS: A Living Logic for AI Agent Teams That Evolve With Humans
arxiv.orgpaper

LOGOS: A Living Logic for AI Agent Teams That Evolve With Humans

LOGOS is a proposed pluggable governance layer that sits on top of existing multiagent frameworks to control how AI agent teams self-modify over time. It compiles heterogeneous inputs into versioned 'agent packs' (agents, tools, knowledge, tests, permissions, policies), records agent activity as auditable event traces, and enforces fail-closed verification so that any learned prompt, memory, skill, tool, or workflow remains an untrusted release candidate until held-out execution evidence and explicit human authorization promote it. The framework targets the core agent-security problem of unauthorized or unverified self-modification in autonomous agent teams.

TL;DR A proposed governance/verification layer that treats every self-learned change in an AI agent team as untrusted until evidence and human authorization approve its promotion.
Also seen from another angle🧠 AI →
Document

What it is

LOGOS (arXiv:2607.10878, Ichikawa et al., Fujitsu/RIKEN/U. Tokyo, July 2026) is a governance layer for self-evolving multi-agent systems. The summary covers the agent-pack/trace/fail-closed-gate architecture; what follows is the design substance an adopter needs but the summary omits: the exact boundary of what agents may not touch, the failure mode it targets, and the effects it explicitly does not cover.

The security boundary: root policy

The paper's core invariant is "proposal is not promotion" — a model must not both propose and approve its own updates. This is enforced by a root policy ($R_{root}$), a human-owned envelope held outside the self-evolution loop. Within a candidate evaluation, agents can copy pack artifacts and sandboxed state, but they explicitly cannot:

  • redefine their objectives or briefs
  • weaken or edit their evaluators/verifiers
  • inspect the final held-out gate set
  • expand their credential envelope
  • authorize irreversible external actions

Promotion requires held-out execution evidence plus proposer-independent policy and authority. Verification only establishes whether a change "appears to work"; policy and approval decide whether it may ship — the paper keeps these two distinct on purpose (see their "Verify" invariant: hard checks are necessary but not sufficient).

Misevolution — the failure mode it targets

The named threat is misevolution: a release artifact changes without evidence that deployment utility improved. Worked example: after an API schema changes, an ungated loop rewrites a prompt (because prompt-editing is available) even though the defect is in the tool schema. The new prompt raises a narrow proxy score while still failing the real API — the system changed, utility fell. This is the concrete argument for gating on held-out evidence rather than proxy metrics.

Rollback does not undo external effects

A caveat the paper stresses and an engineer must internalize: pack rollback restores versions, but it cannot unsend an email, reverse a payment, or undo a database write. LOGOS records external effects in a separate effect log ($\chi_{eff}$); irreversible actions need their own safeguards — previews, transactions, idempotency, compensation, or human confirmation — not rollback.

Preconditions / applicability

LOGOS is pluggable, not a replacement framework. Portability rests on two contracts: a normalizer ($\phi_b$) mapping backend traces into a common trace space, and an emitter ($\epsilon_b$) re-expressing portable artifacts as backend-native ones. Named compatible backends: AutoGen, MetaGPT, OpenHands, OpenAI Agents. The emitter is not a bit-exact replay — it re-expresses and re-verifies a skill on the target backend, and imported knowledge is re-gated on that target.

Caveats

This is a proposal-and-evaluation paper, not a released tool — no code, CVE, or version to act on. "Validated" carries only a narrow meaning here: a pack passed its stated finite probes, not any general safety guarantee. Evaluation is described as bounded (external benchmarks, mechanism studies, fault injection, contract-conformance) with each method used only for the claim it supports; the fetched text does not include the benchmark numbers themselves.

Technologies named here

  • logos