Glossary of terms

Google’s protocol for agent-to-agent communication, enabling interoperability between autonomous agents across different platforms and frameworks.

A Linux Foundation protocol for agent communication, providing a vendor-neutral standard for how AI agents discover, connect to, and interact with one another.

A component that interacts with an AI model to perform a specific task. It is typically backed by a large language model (LLM). It maintains contextual history in a session memory, which may be shared between multiple agents that are collaborating on the same goal. It may provide function tools and call them as requested by the model.

The command-line and marketplace tool that runs Spec-Driven Development from an AI coding assistant. It installs and configures the tools and drives the specify, clarify, plan, tasks, implement, build, and deploy commands.

A recipe that the Akka Specify Plugin turns into runnable AI systems.

AI systems capable of autonomous decision-making, tool use, and multi-step reasoning. Unlike traditional AI that responds to single prompts, agentic AI can plan, execute, and adapt across complex workflows while interacting with external systems.

An Akka component that interacts with an AI model to perform tasks, maintaining session memory. AI Agents can collaborate with other agents, invoke function tools, and leverage Akka’s runtime for durability, resilience, and scalability. See also Agent.

You can deploy Services using a Continuous Integration/Continuous Delivery service. See Integrating with CI/CD tools for instructions.

A command comes from a sender, and a reply may be sent to the sender. A command expresses the intention to alter the state or retrieve information based on the state of an Entity or Workflow. A command is materialized by a message received by a component implementation. Commands are not persisted and might fail.

A command handler is the code that handles a command. It may validate the command using the current state, and may emit events or update the state as part of its processing. A command handler must not update the state of the entity directly, only indirectly by using Effect API.

Effects are predefined operations that align with the capabilities of each Component, except Endpoints. These operations are the Component’s Effect API. Returning an Effect from the Command handler allows the Akka runtime to execute infrastructure-related code transparently to the user. For example, event-sourced entities provide an Effect API that among other things can persist events.

The SDK supports Agent, Endpoint, Key Value Entity, Event Sourced Entity, Workflow, Consumer, View and Timed actions components. These components enable you to implement your business logic.

A utility to call Akka components without knowing where they are located.

An ID to identify components. Changing Component ID for Stateful components should be done with caution, because the ID is used for persistence.

In Spec-Driven Development (SDD (Spec-Driven Development)), the unbreakable rules for an entire project. A constitution defines technology requirements, design mandates, coding standards, and architectural constraints that all generated code must adhere to.

A component used to consume or produce a stream of changes.

An endpoint component is a way to expose a service to the outside world. They act as controllers ahead of the other components, like Entitys or Views. They do not require Component ID because URL address is enough to identify them.

Components like Key Value Entity and Event Sourced Entity are usually referred as entities. An entity is conceptually equivalent to a class, or a type of state. It will have multiple Entity instances, each of which has a unique ID and can handle commands. For example, a service may implement a chat room entity, encompassing the logic associated with chat rooms, and a particular chat room may be an instance of that entity, containing a list of the users currently in the room and a history of the messages sent to it. Entities cache their state and persist it using Effect APIs.

An instance of an Entity, which is identified by a unique ID.

The European Union’s regulation on artificial intelligence, requiring transparency, explainability, and human oversight for AI systems. Akka supports EU AI Act compliance through runtime-embedded governance, audit trails, and policy enforcement via Guardrails.

An event indicates that a change has occurred to an entity and persists the current state. Events are stored in a journal, and are read and replayed each time the entity is reloaded by the Akka runtime state management system. An event emitted by one component or service might be interpreted as a command by another.

An event handler is the only piece of code that is allowed to update the state of the Event Sourced Entity. It receives events, and, according to the event, updates the state.

A type of Entity that stores its state using a journal of events, and restores its state by replaying that journal. These are discussed in more detail in Event Sourced state model.

Runtime policy enforcement mechanisms that validate, filter, or block Agent inputs and outputs. Guardrails ensure AI Agents operate within defined safety boundaries, supporting compliance with regulations such as the EU AI Act.

An id used to identify instances of a Stateful components.

Persistent storage for Events from Event Sourced Entitys. Some documentation uses the terms Event Log or Event Store instead of journal. Akka handles event storage for you, relieving you of connecting to, configuring, or managing the journal.

A Key Value Entity stores state in an update-in-place model, similar to a Key-Value store that supports CRUD (Create, Read, Update, Delete) operations. In Domain Driven Design (DDD) terms, a Value Entity is an "Entity." In contrast with "Value Objects," you reference Entities by an identifier and the value associated with that identifier can change (be updated) over time. These are discussed in more detail in Key Value state model.

AI models trained on large datasets that generate text, code, and structured output. Akka Agents use LLMs as their reasoning engine, with Akka providing the runtime infrastructure for durability, state management, and tool integration.

Anthropic’s protocol for connecting AI models to external tools and data sources. MCP provides a standardized interface for LLMs to discover and invoke tools, retrieve context, and interact with external systems.

Akka supports user management with Single Sign-On via OpenID Connect.

The barrier between AI prototypes and production-grade systems. Prototypes may demonstrate capability but lack the durability, resilience, reliability, and operational readiness required for enterprise deployment. One of the Three Barriers that Akka solves.

A project is the root of one or more Services that are meant to be deployed and run together. The project is a logical container for these services and provides common management capabilities.

An Akka dimension — 99.9999% availability, active-active high availability and disaster recovery (HA/DR), with contractual commitments and indemnities.

An Akka dimension — consistent development across teams via golden paths and Spec-Driven Development. Repeatability eliminates dependency on scarce distributed systems experts by encoding best practices into specifications that AI can execute.

An Akka dimension — runtime-embedded governance, policy enforcement, and EU AI Act compliance. Risk Control includes Guardrails, audit trails, and sanitization to ensure AI systems operate within regulatory and organizational boundaries. One of the Three Dimensions.

When you deploy a Service, Akka wraps it with the runtime. The runtime manages entity state, and exposes the service implementation to the rest of the system. It translates incoming messages to commands and sends them to the service. The runtime also forms a cluster with other instances of the same service, allowing advanced distributed state management features such as sharding, replication and addressed communication between instances.

A data sanitization component that scrubs personally identifiable information (PII) from Agent interactions while preserving explainability and audit trails.

Akka’s primary development approach where specifications are the source of truth and code is AI-generated. SDD uses a Constitution for project-wide rules and individual specs for each component, enabling repeatable, high-quality development without requiring distributed systems expertise.

A service is implemented by the Akka SDK. At runtime, Akka enriches the incoming and outgoing messages with state management capabilities, such as the ability to receive and update state. You implement the business logic for the service, which includes stateful entities. You deploy your services and Akka adds a Runtime that handles incoming communication and persistence at runtime.

A snapshot records current state of an Event Sourced Entity. Akka persists snapshots periodically as an optimization. With snapshots, when the Entity is reloaded from the journal, the entire journal does not need to be replayed, just the changes since the last snapshot.

The barrier where agentic AI delivery depends on scarce distributed systems experts, limiting how many teams can build and operate production AI systems. One of the Three Barriers that Akka solves through Spec-Driven Development and Repeatability.

See SDD (Spec-Driven Development).

The state is simply data—​the current set of values for an Entity instance. Entitys hold their state in memory.

Each entity uses one of the supported state models. The state model determines the way Akka manages data. Currently, these include Key Value Entity and Event Sourced Entity.

A component like Key Value Entity,Event Sourced Entity or Workflow

Files packaged with a Service under src/main/resources/static-resources and served to a browser from an Endpoint. They make up a Web application hosted by the service.

The three challenges preventing enterprises from deploying agentic AI at scale: the Production Gap, Liability, and the Specialist Trap. Akka is designed to overcome all three.

The three ways Akka delivers reliable agentic AI: Reliability, Risk Control, and Repeatability. Together, they address the Three Barriers and enable enterprise-grade AI systems.

A Timed Action provides consistent scheduling and execution of a call to another Component at specified intervals or delays. They are convenient for automating repetitive work and handling timeouts within business logic implementation.

A function, service call, or remote capability an Agent can invoke to gather information or take action. Akka agents call local functions, other components, and remote tools published over MCP (Model Context Protocol).

A View provides a way to retrieve state from multiple Entities based on a query. You can query non-key data items. You can create views from Key Value Entity state, Event Sourced Entity events, and by subscribing to topics.

A browser-facing application served by an Akka Service, made up of Static resources such as HTML, JavaScript, and CSS files, or of HTML generated by an Endpoint at request time. The service that serves the pages also serves the API they call.

Workflows are high-level descriptions to easily align business requirements with their implementation in code. Orchestration across multiple services with support for failure scenarios and compensating actions is simple with Akka Workflows.

A Workflow definition element which encapsulates an action to perform and a transition to the next step (or end transition to finish the Workflow execution).

The business statement of when a feature is done, authored in the project owner’s terms. Each item is translated into one or more exit conditions. See Exit conditions and Definition of Done.

The technical unit of "done" in Spec-Driven Development — a precise, binary pass/fail predicate over an observable surface (an endpoint response, entity state, a build result), backed by an Auditor. See Exit conditions and Definition of Done.

The check bound to an Exit condition that proves the condition’s invariant holds. Akka ships a small set of built-in introspective auditors; beyond those, auditors are authored per ecosystem as inline commands, provisioned as Harness assets, or delegated via Attestation. Every auditor is one of three kinds. See Auditors.

The three forms an Auditor takes, set by where its check can run: introspective (inspects the project tree and returns green or red — the built-in checks and inline authored commands), provisioned (verifies a Harness asset recorded in .akka/harnesses.lock), and delegated (resolved by a recorded Attestation). See Auditor kinds.

A recorded receipt that resolves a delegated check the CLI cannot run in the project’s tree — a run URL, a signature, or the hash of a rubric the assistant applied. The delegated Exit condition resolves deferred until the attestation exists, then green. See Attestations.

A generated configuration asset that connects a project to an external enterprise system — a CI workflow, a scanner configuration, a supply-chain step, or a content-governance package. /akka:harnesses generates it into /harnesses/ and records it in .akka/harnesses.lock; a provisioned Auditor verifies it is present, current, and enforcing. See /akka:harnesses.

An Exit condition whose kind is prohibition: it must never become true, unlike a completion condition, which must become true. An unaudited prohibition is red, because an unenforced ban gives false confidence, and a prohibition cannot be closed by a human sign-off (sign-offs only turn open conditions green). NEVER- is the id-prefix convention, but kind is the switch. See Prohibition conditions.

A material part of the project the Coverage gate accounts for, in one of three classes: code (a build module detected from a marker such as pom.xml, package.json, or go.mod), harness (a required Harness asset), or doc (an enumerable documentable thing such as a command or exit condition). Each class has its own test for "covered", and any uncovered surface reds the gate. A surface can be waived with a recorded reason. See Project surface coverage.

The locked process-integrity gate PROC-AUDITOR-COVERAGE: every material build surface must have a covering Auditor, or the gate is red. Surfaces are detected from markers such as pom.xml, package.json, go.mod, Cargo.toml, pyproject.toml, and Dockerfile, skipping vendored directories. A surface can be waived with a recorded reason. See The coverage gate.

The locked process-integrity gate PROC-ADEQUACY-REVIEWED: a fresh adversarial review, keyed to the current checks, covers every Auditor. The review looks for an input where a check passes while its invariant is false. It is keyed to a signature of the active checks, so feedback that changes a check stales the review and forces a re-run. See The adequacy review.

The rule that a requirement becomes an Exit condition only if a binary pass predicate can be stated that is false exactly when the requirement is violated.

Whether the Definition of Done is a hard gate (Enforced) or an advisory checklist (À la carte). See Choosing your mode.

Where an Exit condition originates — akka-intrinsic, recommended-default, corporate, or developer — which determines whether a developer can change it.

The setting an organization assigns to a governed Exit condition, controlling its default state and whether a developer can change it: always-apply, never-apply, on-but-dev-configurable, or off-but-dev-configurable. See Policies.

A time-bound modifier attached to a still-active Exit condition that records who accepted its unmet state, why, and when the waiver expires. The condition stays visible and reverts to blocking on expiry.

The record written when a feature ships, listing which exit conditions were verified, which deferred downstream, and any waivers in effect. See Shipping and receipts.