Skip to main content

Agentic Architecture Kit

Español · Language policy

Implementation status: 0.4.9 preview. The published distribution is self-contained for agent bootstrap and evolution. The packaged decision core and rule references are normative; the manifesto is their human-facing map. The capability matrix distinguishes implemented, initial, and roadmap behavior.

An executable architecture standard for projects created and evolved by coding agents.

This repository is not a fixed directory template. It provides the protocol and tools an agent needs to discover the smallest justified architecture for a project, materialize it from current knowledge, and protect it as the product evolves.

Primary objective

An agent must be able to create, modify, and evolve a project autonomously within the boundaries decided by the team. The repository must provide enough context, policies, and validation for the agent to determine what it may do, where the change belongs, and how to prove the result conforms—without human intervention unless the request requires a product, risk, ownership, or authority decision that has not yet been defined. The repository must also organize and provide the minimum sufficient context for each task efficiently, progressively, and traceably, so the agent can quickly locate the relevant domain, ownership, contracts, decisions, dependencies, code, and tests without indiscriminate loading or conversational memory.

Autonomy is the default behavior. Human intervention is an exceptional escalation when the repository does not contain enough authority for a material decision; it is not a routine development step.

Context access is part of the architecture. The repository provides a small entry point and lets the agent expand through ownership, dependencies, and concrete evidence. More context is not necessarily better: relevant context should arrive when the task requires it.

What is included

  • MANIFESTO.md: human-facing purpose, enforcement model, and map of the canonical sources.
  • agent-core.md: the complete preventive context an implementation agent reads before deciding structure.
  • portable-rules.md: validator-owned norms loaded progressively through findings.
  • docs/team-guide.md: human guide for understanding, reviewing, and governing the artifacts created by the kit.
  • docs/capabilities.md: honest implementation and roadmap matrix for the reference tools.
  • docs/github-governance.md: required CODEOWNERS, review, and protected-branch controls that cannot be proven locally.
  • docs/releasing.md: package release and PyPI trusted publishing procedure for kit maintainers.
  • docs/create-project-from-zero.md: the web rendition of the operational procedure bundled as aak guide bootstrap.
  • docs/adapter-development.md: compact contract, packaging, and test guide bundled as aak guide adapter-development.
  • docs/pipeline.md: end-to-end CI integration from adapter execution and base comparison through retained evidence and merge protection, bundled as aak guide pipeline.
  • src/agentic_architecture_kit/: versioned Python distribution containing the CLI, operational guides, portable rules, schemas, templates, and built-in technology adapters.
  • tests/: conformance suite for the distributed package.
  • examples/: consumer repositories that exercise the installed rules without vendoring the implementation.

Creating a project

  1. Give the agent write access to the target project directory and access to the package registry, or provide an offline export of the pinned kit version.
  2. Provide the product objective, known requirements, and constraints.
  3. Require it to run aak core and aak guide bootstrap from that version and read both completely before initialization or the first modification.
  4. The agent discovers current capabilities, hosts, and boundaries before creating structure.
  5. It pins and executes a published kit version without copying its implementation into the project.
  6. It adapts the templates to declare the project's actual architecture.
  7. It runs the project's build and tests and validates the resulting architecture.

Copy-paste prompts for coding agents

The agent does not need this source repository. Give it write access to the target directory and package-registry access, replace the bracketed values, and send the appropriate prompt.

Create a new project

Project directory: <PROJECT_DIRECTORY>
Product objective: <PRODUCT_OBJECTIVE>
Known requirements and constraints: <KNOWN_CONSTRAINTS>
Repository CODEOWNER: <CODEOWNER>

Use Agentic Architecture Kit 0.4.9 to create and govern this project.

Before creating or modifying files:

1. Run these commands and read both outputs completely:

   uvx --from agentic-architecture-kit==0.4.9 aak core
   uvx --from agentic-architecture-kit==0.4.9 aak guide bootstrap

2. Treat that version-matched guidance as authoritative for architecture
   decisions. Do not rely on a remembered or copied repository structure.

3. Classify available information as KNOWN, ASSUMED, or UNKNOWN. Propose the
   smallest architecture justified by current evidence. Do not create modules,
   projects, abstractions, directories, or dependencies for hypothetical needs.

4. Before materializing architecture, ask me only for unresolved decisions that
   would materially affect product behavior, risk, ownership, runtime,
   persistence, deployment, or granted authority.

5. Once those decisions are resolved, use `aak init` from the pinned
   distribution with the appropriate adapter, CODEOWNER, and authority mode.
   Create only applicable project-owned contracts and context; do not copy the
   AAK implementation or an example structure into this project.

6. Run `aak validate --fail-on-review` immediately after declaring the minimum
   architecture and before creating product implementation. Follow a finding's
   packaged normative reference when needed. An unresolved reference is a
   failure, not permission to infer the rule.

7. Implement in small verified steps. Run the project's build and tests and the
   architecture gate again before declaring completion. Persist enough project
   context that another agent can continue without this conversation.

While working, explain the current AAK step, discovered facts, decisions,
planned files, validation results, and any unresolved material question.

Adopt AAK in an existing project

Repository directory: <PROJECT_DIRECTORY>
Change objective: <CHANGE_OBJECTIVE>
Known requirements and constraints: <KNOWN_CONSTRAINTS>
Repository CODEOWNER: <CODEOWNER>

Use Agentic Architecture Kit 0.4.9 before making the first project change.

1. Run and read completely:

   uvx --from agentic-architecture-kit==0.4.9 aak core
   uvx --from agentic-architecture-kit==0.4.9 aak guide bootstrap

2. Preview adoption without writing files:

   uvx --from agentic-architecture-kit==0.4.9 aak adopt \
     --root "<PROJECT_DIRECTORY>" \
     --codeowner <CODEOWNER> \
     --ci github \
     --dry-run

3. Explain the observed architecture, proposed policy, planned files, and every
   `requiredActions` item. Do not treat observed structure as automatic
   architectural approval.

4. Ask me only for unresolved material product, risk, ownership, runtime,
   persistence, deployment, or authority decisions. Then apply the same
   `aak adopt` command without `--dry-run`.

5. Preserve existing files and workflows. Never invent module contracts,
   waivers, or semantic approvals. Complete semantic artifacts only from actual
   project evidence and authorized decisions.

6. Run the project's build and tests and `aak validate --fail-on-review` before
   completion. Explain nonzero adoption or validation results as actionable
   findings rather than hiding them or weakening policy.

Distribution and project-owned payload

Portable code, operational agent guides, schemas, the rule catalog, and neutral templates are published together as agentic-architecture-kit. A consumer pins the exact version in .agentic/toolchain.json and runs it with uvx or pipx:

uvx --from agentic-architecture-kit==0.4.9 aak core
uvx --from agentic-architecture-kit==0.4.9 aak guide bootstrap
uvx --from agentic-architecture-kit==0.4.9 aak validate --fail-on-review

The agent does not need access to this source checkout. The pinned distribution contains the preventive core, operational guides, rules, schemas, templates, adapters, and validation engine required for bootstrap and later evolution.

Only project-owned decisions and context live in the consumer repository:

AGENTS.md
architecture/system-overview.md
architecture/decisions/
domain/global-invariants.md
.agentic/toolchain.json
.agentic/policies/architecture/project-policy.json
.agentic/policies/architecture/waivers.json
.agentic/policies/architecture/authorities.json
.agentic/policies/architecture/reviews.json
.github/CODEOWNERS
{actual-module-root}/AGENTS.md
{actual-module-root}/module.contract.yml

Only applicable artifacts are created. Empty directories, speculative abstractions, technical modules, and assemblies without a current enforceable boundary are prohibited.

For disconnected environments, aak export-offline --output <directory> creates an explicit versioned snapshot containing the same code, guides, schemas, rules, and templates with a SHA-256 manifest. That export is an operational exception, not the default adoption model.

Adopting AAK in an existing project

Run the adoption preview from the existing repository root before modifying the project. It observes the current Python or SDK-style .NET structure and reports every file it would add, the proposed policy, CI integration, validation result, and semantic work that still requires a real decision:

uvx --from agentic-architecture-kit==0.4.9 aak adopt \
  --root . \
  --codeowner @your-org/architecture \
  --ci github \
  --dry-run

Review the JSON plan, then apply the same command without --dry-run:

uvx --from agentic-architecture-kit==0.4.9 aak adopt \
  --root . \
  --codeowner @your-org/architecture \
  --ci github

For a single-owner repository, add --authority-mode solo-maintainer and use that maintainer as --codeowner. aak adopt refuses a dirty worktree unless --allow-dirty is explicit. It preserves existing files and workflows, so re-running it is safe; an existing workflow without the AAK gate is reported for integration instead of being overwritten.

The command automates the mechanical bootstrap: governance records, observed policy proposal, optional GitHub Actions gate, strict validation, and the context index. It exits nonzero when conformance or semantic work remains and lists that work under requiredActions. It never fabricates module contracts, local AGENTS.md content, waivers, or semantic approvals. Complete those items from actual project knowledge. Route implementation through aak guide implement-change and create contracts through aak guide module-contract-authoring-prompt. Create or reconcile policy through aak guide project-policy-authoring-prompt, and create or maintain ADRs, invariants, overviews, and routers through aak guide architecture-context-authoring-prompt; the user supplies product meaning and architectural intent, not artifact syntax. Run the project build and tests, and rerun aak validate --fail-on-review before merging.

Verifying the kit

Python 3.9 or later is required. The kit has no third-party runtime dependency.

python3 -m pip install --no-deps -e .
python3 -m unittest discover -s tests -v
aak --help
aak validate --fail-on-review
aak core
aak guide
aak guide architecture-context-authoring-prompt
aak guide bootstrap
aak guide github-governance
aak guide implement-change
aak guide module-contract-authoring-prompt
aak guide pipeline
aak guide project-policy-authoring-prompt
aak guide project-rule-authoring-prompt
aak guide waiver-authoring-prompt
aak template
aak template AGENTS.md
aak adopt --help
aak explain DEP001
aak context index
aak context locate "architecture validation"
aak validate --root examples/dotnet-valid

For lower-level or new-project initialization, aak init creates governance files and writes an observed project-policy.json proposal without running the complete adoption workflow:

uvx --from agentic-architecture-kit==0.4.9 aak init --root . --codeowner @your-org/architecture

For a repository maintained by one person, declare that constraint honestly instead of configuring an impossible self-review requirement:

uvx --from agentic-architecture-kit==0.4.9 aak init --root . \
  --codeowner @your-user --authority-mode solo-maintainer

Solo-maintainer reviews use a durable GitHub maintainer-attestation URL. They do not claim that approving one's own pull request is independent review.

For an empty repository, select the known technology explicitly with --adapter dotnet or --adapter python. The observed proposal is a starting point, not approval of every discovered boundary: review it and remove accidental or unjustified structure before implementation.

The reference implementation supports SDK-style .NET and Python projects. See examples/dotnet-valid/ for a conforming repository and examples/dotnet-invalid/ for an intentional source-level architecture failure inside a single assembly.

License

Agentic Architecture Kit is licensed under the Apache License 2.0 (Apache-2.0).

Metadata

Release files for agentic-architecture-kit 0.4.9

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for agentic-architecture-kit 0.4.9
File Size Uploaded Provenance
agentic_architecture_kit-0.4.9.tar.gz 131.2 kB With provenance Details

Built distribution (wheel)

Table of built distributions (wheels) for agentic-architecture-kit 0.4.9
File Interpreter ABI Platform
agentic_architecture_kit-0.4.9-py3-none-any.whl Python 3 none any Details

Total release size: 275.1 kB

Release files / agentic_architecture_kit-0.4.9.tar.gz

Download URL agentic_architecture_kit-0.4.9.tar.gz
Size 131.2 kB
Tags Source
SHA-256 checksum
How to use checksums
322f988bd1b1d4c505b1e45df1ead68ce42205bb6ade7b2d47a5e0059e16cc3c
BLAKE2b-256 checksum
How to use checksums
472552bb4c9b43183c366b2aa941989bbd800e731413215de1d9d2e899330c3e
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Sep 3, 2026.

Transparency log

Release files / agentic_architecture_kit-0.4.9-py3-none-any.whl

Download URL agentic_architecture_kit-0.4.9-py3-none-any.whl
Size 143.9 kB
Tags Python 3
SHA-256 checksum
How to use checksums
c036c1c22a89caab3e6feea5ac45447dba5c4ba94a5460f3e9602c1444088ecf
BLAKE2b-256 checksum
How to use checksums
985c8b03825289af1d3beef4f886b9f81e0abd2db15aaed83f1d709d85d799e4
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Sep 3, 2026.

Transparency log

Security for agentic-architecture-kit 0.4.9

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

Full provenance

All 2 files in this release have been uploaded with provenance metadata.

Select from 2 files

Attestation for agentic_architecture_kit-0.4.9.tar.gz

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Sep 3, 2026.

Transparency log

A note on package security

PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page