Skip to main content
This page is for AFK maintainers. It explains how to change public exports without making downstream code or docs confusing. For the user-facing import table, see API Reference.

Contract

The public API is the set of names exported by package-level __init__.py files:
  • afk.agents
  • afk.core
  • afk.tools
  • afk.llms
  • afk.memory
  • afk.queues
  • afk.mcp
  • afk.messaging
  • afk.observability
  • afk.evals
Public docs and examples should import from these package surfaces. They should not use src.afk imports or deep implementation modules such as afk.core.runner.api.

Rules for maintainers

  1. If a downstream user should import a symbol, export it from the package-level __init__.py.
  2. If a symbol is not exported, do not use it in builder docs or examples.
  3. Keep Agent and Runner separate: Agent comes from afk.agents; Runner comes from afk.core.
  4. Prefer protocols, dataclasses, Pydantic models, and explicit error classes for public contracts.
  5. When removing or renaming a public symbol, update migration docs and tests in the same change.
  6. When changing a public constructor, update API Reference, Configuration Reference, examples, and generated agent-facing docs.

Preferred examples

Imports to avoid in public docs

Deep imports are acceptable in internal tests only when the test is specifically covering an internal unit. Integration tests and examples should exercise the public surface.

Change checklist

Before merging a public API change:
  • Update the relevant package __all__.
  • Add or update tests that import through the public package.
  • Update user-facing docs if a builder would see the changed behavior.
  • Update maintainer docs if an invariant or subsystem boundary changed.
  • Run PYTHONPATH=src pytest -q or targeted tests for the affected subsystem.
  • Regenerate agent-facing docs with ./scripts/build_agentic_ai_assets.sh when docs, examples, skill metadata, or navigation changes.

Search commands

The last command intentionally finds deep imports for review. Some maintainer references may be valid, but builder docs should avoid them.