This release (8.21.6) delivers key enhancements to the Equinox Agentic AI platform. It introduces the Agent‑to‑Agent (A2A) module for standardized agent discovery and task‑based communication, document‑driven execution in AI Studio, and centralized management of prompts, skills, and guardrails. The release also adds custom role‑based access control (RBAC) for Agentic AI, enabling secure, role‑based access across agents, workflows, and supporting components.

A2A (Agent-to-Agent) Module

API/Technical Changes

The following Agent‑to‑Agent (A2A) APIs have been introduced:

  • GET /a2a/agents — Retrieves the list of available agents for Agent‑to‑Agent discovery.
  • GET /a2a/agents/{agentId}/extendedAgentCard — Returns the extended agent card for the specified agent.
  • POST /a2a/tasks — Creates a new A2A task.
  • GET /a2a/tasks — Retrieves the list of tasks
  • GET /a2a/tasks/{taskId} — Retrieves details for a specific task.
  • POST /a2a/tasks/{taskId}/send — Sends a message to the specified task.
  • GET /a2a/tasks/{taskId}/events — Streams task lifecycle and message events using Server‑Sent Events (SSE).
  • POST /a2a/tasks/{taskId}/push-notifications — Creates a push notification configuration for task events.
  • GET /a2a/tasks/{taskId}/push-notifications — Lists existing push notification configurations for the task.

Functional Changes

The A2A module uses the A2A v1.0 protocol to allow Equinox AI agents to communicate with other A2A‑compatible agents. It works in two ways:

  • as a server, it makes Equinox agents available for others to find and use
  • as a client, it sends messages to external agents

Core Capabilities

  • Agent Discovery
    Equinox publishes standard Agent Cards at /.well-known/agent-card.json. These cards tell other systems which agents are available, what they can do, and how to authenticate. An extended card (available only with authentication) shows internal details like LLM configuration, MCP tools, and knowledge bases.
  • Task-Based Messaging
    Each request creates a task. The task moves through states such as SUBMITTED → WORKING → COMPLETED / FAILED / CANCELED. Tasks store message history, outputs (artifacts), and execution details like tokens, cost, and time.
  • Synchronous and Asynchronous Execution
    Clients can wait for the task to finish or get an immediate response and check progress later. Real‑time updates are available using SSE streaming (tasks/{id}:subscribe).
  • Push Notifications
    Clients can register webhooks to receive task status updates automatically instead of polling. Callbacks can use token-based or bearer authentication.
  • Remote Agent Client
    Equinox can send messages to external A2A agents using A2AClient. The A2ACardResolver handles discovery of remote agents, with built‑in retry logic and configurable timeouts.

Attachments as Query Source in AI Studio

API/Technical Changes

Support for attachments as query sources has been added to AI Studio execution APIs. These updates allow agents and workflows to accept file attachments via multipart uploads and automatically surface them as execution‑time attachments.

The following Execution APIs have been introduced with support for multipart file uploads:

  • POST /agents/{agent_id}/execute:

    • Executes an agent with optional file attachments via multipart/form-data.

    • Uploaded files (field name: files) are extracted and passed into the agent execution context.

  • POST /workflows/{workflow_id}/execute:

    • Executes a workflow with optional file attachments via multipart/form-data.

    • Uploaded files (field name: files) are extracted and passed into the workflow execution context.

Functional Changes

This update enables document‑driven execution in AI Studio by allowing file attachments to serve as the primary query input, streamlining workflows and reducing manual text entry:
  • Introduced the ability to use attachments as the query source, removing the need to type long or detailed text-based queries.
  • Users can now upload documents such as PDF, Excel sheets, and Word files directly within AI Studio.
  • The system uses the content of the attached file as the input for execution, allowing queries to be driven by existing documents.
  • This enhancement improves usability by reducing manual effort, especially when working with complex or information-heavy files.

Prompt Library

API/Technical Changes

The following APIs have been introduced to manage and render Prompt Templates:

  • POST /prompts — Create a prompt template
  • GET /prompts — List prompt templates
  • GET /prompts/{prompt_id} — Retrieve a prompt template
  • PUT /prompts/{prompt_id} — Replace a prompt template
  • PATCH /prompts/{prompt_id} — Update a prompt template
  • DELETE /prompts/{prompt_id} — Soft delete (archive) a prompt template
  • POST /prompts/{prompt_id}/render — Render a prompt template
  • GET /prompts/{prompt_id}/versions — Retrieve prompt version history
  • GET /prompts/{prompt_id}/content — Retrieve raw prompt content (optionally by version)

Functional Changes

This enhancement centralizes prompt creation and versioned management, enabling consistent, reusable, and easily updatable prompts across agents.

  • Introduced a Prompt Library that allows admin users to create and manage prompts for different agents from a central place.
  • The same prompt can be reused across multiple agents, ensuring consistency and reducing duplicate prompt creation.
  • Prompts can be updated at any time, making it easy to refine or improve agent behavior.
  • Each update creates a new prompt version, enabling version tracking and control.
  • Users can select and apply the appropriate prompt version when configuring or executing an agent.

Custom Roles & RBAC for Agentic AI

This release establishes comprehensive RBAC with role‑ and scope‑based controls, enabling precise governance, secure operations, and differentiated access across the Agentic AI platform:

  • Introduced custom role‑based access control (RBAC) for Agentic AI with clearly defined roles: AI Studio Admin, AI Studio Manager, and AI Studio User, ensuring controlled and secure access across modules.
  • Implemented module-level permission matrices across MCPs, LLM Providers, Knowledge Bases, Guardrails, Agents, and Workflows, defining precise capabilities such as view, create, update, delete, execute, and test actions per role.
  • Enabled scope-aware access control (Global / Business / Store), allowing Admins to operate across all scopes, Managers to work within accessible business and store scopes, and Users to operate primarily within their own store scope.
  • Restricted mutation and scope transitions based on role, where Admins can broaden or change scopes, while Managers and Users have limited or read-only permissions for sensitive operations.
  • Enhanced governance by supporting read-only vs full-access behaviors, soft vs hard deletes, execution controls, and differentiated permissions for agent creation, workflow execution, knowledge base management, and guardrail testing.

Guardrail Configuration Utility

API/Technical Changes

The following APIs have been introduced to create, manage, test, and evaluate Guardrails:

  • POST /guardrails — Create a guardrail
  • GET /guardrails — List guardrails
  • GET /guardrails/secrets — List guardrail secrets from AWS Secrets Manager
  • GET /guardrails/secrets/{secret_name:path} — Retrieve guardrail secret details from AWS Secrets Manager
  • GET /guardrails/{guardrail_id} — Retrieve a guardrail
  • PUT /guardrails/{guardrail_id} — Replace a guardrail (full update)
  • PATCH /guardrails/{guardrail_id} — Update a guardrail (partial update)
  • DELETE /guardrails/{guardrail_id} — Soft delete a guardrail
  • POST /guardrails/{guardrail_id}/test — Test a guardrail
  • POST /guardrails/evaluate — Evaluate content against multiple guardrails

Functional Changes

This enhancement enables API‑based, runtime management of AWS Bedrock guardrails with safe, versioned, and partial updates, improving governance without relying on the AWS Console or CLI:

  • Introduced a runtime Guardrail Configuration Utility that allows reading and updating AWS Bedrock guardrail settings through HTTP APIs, removing the need to use the AWS Console or CLI.
  • Added a GET endpoint to retrieve the complete current guardrail configuration for eq-platform-guardrails, reflecting the version specified by configuration (default version 1).
  • Added a POST update endpoint that supports partial configuration updates, where new values are merged with the existing guardrail configuration while preserving unchanged policies.
  • Enabled optional publishing of guardrail versions, allowing updates to be promoted to an immutable version once published.
  • Implemented safeguards such as policy-level replacement behavior, automatic removal of read-only fields during updates, and controlled handling of concurrent updates with a last-write-wins approach.

Skills

API/Technical Changes

The following APIs have been introduced to manage Skills, including versions and reference files:

  • POST /skills — Create a skill
  • GET /skills — List skills
  • GET /skills/catalog — Retrieve the skill catalog
  • GET /skills/{skill_id} — Retrieve a skill (includes full instructions)
  • PATCH /skills/{skill_id} — Update a skill (partial update)
  • DELETE /skills/{skill_id} — Soft delete (archive) a skill
  • GET /skills/{skill_id}/versions — Retrieve skill version history
  • GET /skills/{skill_id}/files/{filename} — Retrieve a skill reference file

Functional Changes

This update introduces reusable, versioned, and scope‑aware Skills that package instructions, tools, and reference files to help agents perform specialized tasks efficiently while optimizing token usage:

  • A skill is a reusable package that helps an AI agent do a specific job better (domain knowledge, guidance, and/or tools).
  • Each skill has a name and a short description so the agent can quickly understand what it’s for.
  • Skills come in three types:
    • Prompt skill: gives the agent written instructions/knowledge.
    • Tool skill: gives the agent access to specific tools plus how to use them.
    • Composite skill: provides both instructions and tools.
  • Skills are shared with the agent in layers to save tokens:
    • Tier 1 (Catalog): short description shown frequently.
    • Tier 2 (Instructions): full detailed instructions loaded only when needed.
    • Tier 3 (Reference files): supporting documents loaded one-by-one when needed.
  • A skill can include tool usage instructions that tell the agent the right way to call the bundled tools.
  • A skill can include reference files (supporting documents) that the agent can fetch when it needs more detail.
  • Skills can be scoped so they are visible only to:
    • one store,
    • the whole business,
    • or globally across all tenants (depending on permissions).
  • Skills have a status (e.g., active/archived) that controls whether they show up for use.
  • Skills support versioning so changes to instructions can be tracked over time.

To Do List

Functional Changes

This feature enables structured, observable task planning by letting agents maintain a live, tool‑driven todo list with real‑time status updates throughout multi‑step execution:

  • What it is: “Task Planning Enabled” turns on a structured planning capability for an agent by giving it a dedicated tool called <strong>write_todos</strong> (instead of letting it write an informal plan in chat text).
  • Why it exists: It makes multi-step agent work observable and trackable (for users and the UI) by keeping a live todo list with statuses as the agent progresses.
  • How it’s enabled:
    • For normal EQ agents: set <strong>enable_planning = true</strong> on the agent configuration.
    • For graph (multi-agent) setups: you can enable it per inline member agent via <strong>InlineAgentConfig.enable_planning = true</strong>.
  • What the tool does:
    • The agent calls <strong>write_todos</strong> to create/update a todo list.
    • Each todo item includes: id, short task content, and a status.
  • Statuses supported: pending, in_progress, completed, failed.
  • Full-replace update model: Every time the agent updates the plan, it must send the entire todo list again (not just changes). The new list replaces the old list.
  • Constraints / guardrails on the plan:
    • Todo list must have at least 1 and at most 20 items.
    • Each item’s text is kept short (bounded length) to prevent huge plans.
  • Prompt enforcement (behavioral contract): A planning instruction block (PLANNING_PROMPT_SUFFIX) is intended to be injected into the agent prompt so the model is forced to use the tool when:
    • the user asks for a plan/todo/checklist, or
    • the task clearly has multiple steps/tool calls.
  • Real-time UI updates (streaming): When write_todos runs, it tries to emit a streaming event (type: "todos") through the graph engine’s context writer so the frontend can show the plan live and update progress in real time.
  • What the user sees during execution:
    • A live-updating task list panel (from the "todos" streaming event), and/or
    • a short “plan updated” textual summary (returned by the tool) for logging/history.
  • State is mainly execution-scoped: The current todo list is stored in the tool instance in memory for the duration of that agent run; long-term persistence would require extra wiring (not inherent to the tool itself).
  • Core value: It converts “agent reasoning/planning” into a structured, UI-friendly progress tracker that can be updated step-by-step as the agent works.

 

Revision History
2026-04-30 | JP – Added AI Studio changes for Release 8.21.6