Glossary of terms

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

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 plugin, installed in your Harness, that runs Spec-Driven Development. It drives commands such as /akka:specify, /akka:plan, /akka:tasks, /akka:implement, /akka:converge, /akka:status, /akka:conform and /akka:ship. See Specifications and conformance.

A recipe that the Akka Specify Plugin turns into runnable AI systems. See Specifications and conformance.

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 Authenticate CI/CD for instructions.

A named, config-bound unit that maps input text to a score or label, with optional confidence and attributes. A guardrail, an Evaluator, a sanitizer, or application code invokes it by name through a ClassifierClient. A classifier can compose other classifiers into an ensemble. A Routing classifier is a different thing. See Classifiers.

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, the ledger, and policy enforcement via Guardrails.

A Component that assesses Agent interactions. Bound to one or more agents in configuration, the runtime triggers it for each interaction of a bound agent, out of band, and records its verdict (pass/fail, with optional score, label, and attributes). An evaluator reads the interaction it assesses from the Ledger and may delegate the verdict to an LLM (Large Language Model)-as-judge agent. See Evaluation and Evaluators.

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.

A control type that checks an agent’s input, tool call or output at a runtime boundary and blocks or passes it. The verdict of a guardrail is Evidence in the Ledger. See Guardrails.

An obligation plus the mechanism that meets it. Every control has an id, is one of five control types, and produces verdicts that name it. See Controls.

One of the five kinds of Control: guardrail, sanitizer, eval, human decision and gate. See The five control types.

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.

The trace of what happened in an agentic system. Each interaction is saved in it as a Record: the model calls, tool calls, token usage and outcome, and the verdicts of the controls that applied. An Evaluator reads from it through an injected LedgerClient. See The ledger and evidence and The ledger client.

The saved information about one interaction or event, as one entry in the Ledger. See The ledger and evidence.

The capture of a Control verdict, kept in the Ledger with the record it was decided on. See The ledger and evidence.

The input and output of one exchange that passed through the agent gateway. Captures feed grading, routing and training. See concepts:model-training.adoc#capture-and-grading.

Either an agentic AI trace that is saved as a Record in the Ledger, or a Capture of traffic in the agent gateway. A page that uses the word says which. See The ledger and evidence.

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.

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.

How Akka keeps services available and their state durable: state recovered from events, regions spread across availability zones, and state replicated between regions. See Availability and recovery.

The Akka runtime runs each Service as a cluster of nodes. It keeps component state in memory with one owner for each instance, routes messages to that owner, rebuilds state from events after a failure, and replicates state between regions. See The runtime.

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

A way of building an application from plain-language specifications that are versioned with the code, and of checking the code against them. SDD uses a Constitution for project-wide rules and a specification for each feature. See Specifications and conformance.

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 SPIFFE identity is the workload identity Akka assigns each component, encoding the calling Service, component type, and component id (for example spiffe://trust/svc/checkout/workflow/order). It enables access control per component instead of per service, matched in an @Acl or read programmatically, and is propagated across service boundaries. The service-level part is attested by the service mesh and cannot be spoofed. See Access Control Lists (ACLs).

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.

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

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.

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).

A region with a primary role, for an entity or for a project; the docs always say which. An entity’s primary region is the region that accepts its writes: where it was created, and in request-region mode wherever it was last written; in pinned-region mode, the project’s primary region. A project’s primary region is the region its resources replicate from. See Replicated reads and the primary region.

A model that a routing rule hands its decision to, to choose where a request goes. It is not the governance Classifier. See concepts:models.adoc#model-routing.

The name a client sends to call a served model or adapter, and the name that spend is priced by. It is the model field of the response body. See concepts:models.adoc#model-serving.

A limit on the cost of model traffic for a period, checked against the spend that the pricing catalog computes. See concepts:model-training.adoc#spend-and-budgets.

A kind of task discovered from traffic, which is routed, graded and trained as one unit. See Use cases.

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 (check). 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 (check)). 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 stays open with reason needs-user-action until the attestation exists, then goes green. See Attestations.

The AI coding assistant in which you run the Akka Specify Plugin. Akka Specify also generates harness assets, which are a different thing.

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 Conformance modes.

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 property on an Exit condition that records who accepted its unmet state, why, and when the waiver expires. The condition’s state is unchanged — the auditor still runs and the state still shows what it decided — but a waiver permits shipping despite red or open. On expiry the waiver is removed and the condition returns to blocking. A control waiver in governance is a different decision; see From risk to controls. See Exit condition states.

A property on an Exit condition that says whether the condition applies to this project. An inapplicable condition stays visible on the manifest with an applicable = false marker and does not count for the ship verdict. Set through /akka:scope or by a policy strike on a recommended-default condition.

The moment an Exit condition must be green. One of author (developer’s own loop, precondition for every ship), review (before opening the change for team review), or release (before releasing to production). Tiers are monotonic — every ship at any target requires every author-tier condition to be green. See Ship tiers.

One of open, green, or red. Set by the condition’s auditor. When state is open, a reason is set to either needs-user-action or blocked-outside-project. See Exit condition states.

A timestamp on an Exit condition set when its auditor last returned green. Used by /akka:ship to detect drift: if any file in the project has been modified after verified_at, the condition is marked stale and the ship refuses until the auditor re-runs.

The record written when a feature ships, listing which exit conditions were green, which stayed open and why, and any waivers in effect. See Shipping and receipts.