Autogenesis boundary

Type: agentic-system-analyses/types/agentic-system-boundary.md

Boundary and evidence

This run analyses Autogenesis as an enclosing multi-agent runtime, including its capability-generation and improvement plane, memory and context assembly, workflow execution, durable project state, and shipped clients. The intended use is to establish how its components operate together, not to treat its memory API or evolution playbook as a standalone product. The boundary is whole-system at the registered repository revision. It includes both the Gateway path and directly bootstrapped Python example drivers; neither is an external host.

The frozen evidence is SRC-1 at 5b070d5cd497e951a188a01409138e8b530eaf4a, with an applicability cutoff of 2026-10-19. HEAD matched that revision and the tracked working tree had no diff against it during boundary inspection. The overall tier is code-grounded: executable source supplies implementation evidence; bundled prompts, skills and module documentation supply doctrine/design evidence. No target code, tests or examples were executed. Test definitions are inspectable implementation evidence, not observed passing runs. This boundary establishes neither production reliability nor measured improvement from self-evolution.

Classification and loop coverage

Autogenesis issues model calls and owns agent execution rather than merely returning a tool result to an excluded runtime. The installed console entry resolves to autogenesis.cli:main (SRC-1, pyproject.toml). That console starts or calls the Gateway, whose startup initializes capability managers, starts task workers and restores sessions (SRC-1, autogenesis/cli.py, autogenesis/gateway/service.py). The runtime itself owns spawned agent references and message handling (SRC-1, autogenesis/runtime/server.py).

"""One-shot: spawn + ask(TaskMessage) + stop. Returns agent's result.""" --- autogenesis/runtime/server.py

The agent's decision path streams a configured model with assembled messages and native capability schemas; source inspection is sufficient to classify the system as model-dependent, without assuming a successful provider call (SRC-1, autogenesis/agent/types.py).

acc = await accumulate_stream( model_manager.stream( name=self.model_name, input={"messages": messages, "tools": tools}, ctx=ctx, ) ) --- autogenesis/agent/types.py

The functional boundary includes state producers, maintainers, admission paths and subsequent consumers. Lifecycle hooks emit events into primary memory and a file-system sink; tiered memory renders and persists session state; agent context assembly reads the selected memory for prompt injection. This traces a shipped producer-to-consumer path, but does not establish that persisted tiered memory is rehydrated after process restart (SRC-1, autogenesis/hook/default/memory.py, autogenesis/memory/default/tiered.py, autogenesis/agent/types.py). Conversation persistence and transcript replay are distinct retained-state paths, not evidence that every memory backend reloads (SRC-1, autogenesis/conversation/server.py, autogenesis/gateway/service.py, frontend/src/App.tsx).

mem_text = await memory_info.instance.get( session_id=session_id, short_term_n=self.review_steps, ) --- autogenesis/agent/types.py

Capability evolution is also inside the boundary: generators, optimizers, evaluators, their prompts and creator skills, registration hooks, staging/promotion, extension manifests, smoke checks, archived versions and rollback controls. An inspected skill registration path promotes a staged directory and registers it as evolvable; extension registration exposes a smoke-gate/revert path (SRC-1, autogenesis/hook/default/skill_registration.py, autogenesis/hook/promotion.py, autogenesis/extension/server.py). These mechanisms must be distinguished from the playbook's register-is-live claims. The playbook is design evidence, not proof that all contemporary admission paths lack staging or validation (SRC-1, autogenesis/skill/creator/self_evolving_skill/SKILL.md).

name = await extension_manager.add_component("skill", skill_dir, config={"enable_evolving": True}) --- autogenesis/hook/default/skill_registration.py

Workflow and canvas callers remain included. The workflow runtime invokes the same capability managers and has checkpoint/resume paths; Gateway endpoints save, run and reopen canvas flows. Python examples likewise submit tasks through shipped task and agent managers rather than constituting excluded enclosing applications (SRC-1, autogenesis/workflow/runtime.py, autogenesis/canvas/server.py, autogenesis/gateway/service.py, examples/run_general_agent.py).

Top-level coverage

Every top-level tracked entry is classified below. Included means part of the analysis's functional/evidence scope, not a claim that every file has already been read. “Not yet inspected” names available material, not an access gap. All path references in this table refer to SRC-1.

External dependencies and evidence limits

Provider implementations, network services, credentials, MCP server deployments, browser/container engines and installed dependency internals are not frozen by this run. Autogenesis's adapters, permission checks, configuration and launch code remain included. These external limits prevent conclusions about actual model quality, remote service availability, deployment security, tool success and reproducible end-to-end performance. Dependencies and optional browser/sandbox/benchmark integrations are declared in SRC-1, pyproject.toml; adapters and connectors are present in the tracked tree.

No execution traces or experimental results were separately supplied or frozen. The register therefore contains no observed-run or causal-experiment layer. A comparison probe prescribed by a skill or an evaluator class is not evidence that an intervention helped. Unread tracked files remain accessible within SRC-1; they are not missing evidence or permission to substitute another revision.

Source register