Network Working Group S. Sharaf Internet-Draft Independent Intended status: Standards Track 25 October 2026 Expires: 28 April 2027 BRICK: Portable Definition and Composition of AI Agents draft-sharaf-brick-agent-definition-00 Abstract BRICK proposes a vendor-neutral JSON construction contract for AI agents. It defines agent identity, goals, capabilities, instruction and skill references, explicitly namespaced MCP tool dependencies, and an optional projection to A2A Agent Cards. It references the existing MCP, A2A, and Agent Skills specifications rather than redefining their protocols or formats. BRICK does not prescribe a language model, reasoning engine, deployment platform, discovery service, or authorization protocol. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 28 April 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Sharaf Expires 28 April 2027 [Page 1] Internet-Draft BRICK Core October 2026 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Scope and Requirements Language . . . . . . . . . . . . . . . 3 3. Terminology and Agent Definition . . . . . . . . . . . . . . 3 4. Core Building Blocks . . . . . . . . . . . . . . . . . . . . 3 5. JSON Manifest and Schema . . . . . . . . . . . . . . . . . . 4 6. Instructions and Agent Skills Composition . . . . . . . . . . 4 7. MCP Dependency Binding . . . . . . . . . . . . . . . . . . . 5 8. A2A Agent Card Projection . . . . . . . . . . . . . . . . . . 5 9. Security and Privacy Considerations . . . . . . . . . . . . . 5 10. Conformance and Extensibility . . . . . . . . . . . . . . . . 6 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 Appendix A. Example BRICK Core Manifest . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction AI agent runtimes commonly represent goals, instructions, use cases, tools, and executable skills in framework-specific configurations. This fragmentation complicates exporting, reviewing, and recreating agent definitions across runtimes. The Agent2Agent (A2A) protocol specifies how independent agents communicate, the Model Context Protocol (MCP) specifies interactions with tools and resources, and Agent Skills specifies reusable skill packages. These specifications do not by themselves provide a portable construction contract for a complete agent. BRICK proposes a vendor-neutral manifest for declaring an agent's building blocks and their references, without standardizing reasoning algorithms or hosting environments. It is designed to complement, not replace, ADK, Agentforce, or other frameworks. Related prior work includes the IETF Agent Definition Language Internet-Draft (draft-nederveld-adl), with which harmonization is encouraged. Sharaf Expires 28 April 2027 [Page 2] Internet-Draft BRICK Core October 2026 2. Scope and Requirements Language The key words MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY are to be interpreted as BCP 14 (RFC 2119 and RFC 8174), only when capitalized. This proposal defines a manifest information model, JSON representation, reference resolution, and basic conformance. It does not define an agent transport, an MCP extension, a new A2A Agent Card, a trust registry, prompt formats, or a universal reasoning algorithm. Governance and delegation profiles are future extensions, not required to construct a BRICK Core agent. 3. Terminology and Agent Definition Agent: A software entity that accepts input, uses instructions and context to select operations, and seeks declared goals under runtime- enforced constraints. BRICK agent: An agent whose portable construction contract is described by a BRICK manifest. Capability: A user-meaningful responsibility or use case of an agent, with explicit dependencies. A capability is not the same thing as an MCP tool, an Agent Skills package, or an A2A advertised skill. Skill: Reusable task instructions and assets referenced by an Agent Skills-compatible package, typically containing SKILL.md. Tool reference: A qualified identifier naming one tool at one declared MCP server. A2A projection: A public Agent Card generated from a subset of an agent's manifest; private instructions and tool inventories are not copied. 4. Core Building Blocks A BRICK Core manifest MUST declare brickVersion, agent, at least one goals entry, and at least one capabilities entry. Agent identity consists of a stable URI id, a human-readable name and description, and a version. Sharaf Expires 28 April 2027 [Page 3] Internet-Draft BRICK Core October 2026 A capability MUST have a stable local id and description. It MAY declare inputs, outputs, skillRefs, toolRefs, and whether it may be publicly advertised. Each skillRefs entry MUST resolve to a skills[].id. Each toolRefs entry MUST use server-id:tool-name and resolve to a tool in that server's allowedTools. A manifest consumer MUST reject unresolved or ambiguous references rather than silently ignore them. instructions and skills entries identify referenced resources using an id and uri, and MAY carry a sha256 digest. The runtime MUST keep source content and provenance separate from higher-trust runtime policy. Referenced files MUST NOT silently introduce new MCP or A2A permissions. runtime and extensions are intentionally nonportable. Consumers MUST NOT interpret their presence as proof of support for proprietary behavior. 5. JSON Manifest and Schema BRICK Core manifests are UTF-8 JSON objects. This draft's companion brick-core-v0.5.schema.json is the candidate validation schema and example-agent.json illustrates its use; publication of a stable, immutable schema URI is an open issue before a Standards Track RFC. Unknown top-level members are rejected by the candidate core schema, while extensions MAY be carried inside extensions. Syntactic JSON Schema validation is necessary but not sufficient. Implementations MUST additionally check uniqueness of all local identifiers, existence of references, transport endpoint policy, and whether any advertised capability can be projected to an A2A Agent Card without disclosing private configuration. Version 0.5 denotes this experimental BRICK manifest format and is not an IETF RFC or an A2A version. 6. Instructions and Agent Skills Composition An instructions entry MAY reference AGENTS.md, which provides project or contextual guidance. A skills entry MAY reference a package's SKILL.md under the Agent Skills specification. BRICK does not redefine either format. Their respective parsers and scoping rules apply. Sharaf Expires 28 April 2027 [Page 4] Internet-Draft BRICK Core October 2026 A runtime MUST distinguish externally supplied instruction text from privileged system, application, or policy instructions. A skill's scripts and references MUST be authorized independently before execution. A missing mandatory reference is a conformance error for implementations that claim the capability depending on it. 7. MCP Dependency Binding A BRICK manifest MAY declare zero or more mcpServers. Each server has a unique local id, a transport, an endpoint, and an explicit allowedTools array. streamable-http and stdio are the baseline declaration values; actual connections MUST follow MCP's negotiated protocol and transport semantics. Tool references use server-id:tool-name. This namespace prevents collisions across separate MCP servers. Runtime implementations MUST NOT expose undeclared tools through BRICK capabilities and MUST apply authorization and least privilege independently for every server. An MCP server endpoint MUST NOT be treated as trustworthy solely because it is listed in the manifest. stdio commands and environment secrets are intentionally out of scope for this minimal portable profile. 8. A2A Agent Card Projection The optional a2a object declares that a conforming runtime MAY expose the agent through A2A. If enabled is true, endpoint and protocolVersion MUST be supplied and a conforming implementation MUST produce an Agent Card using the A2A specification for that protocol version. The a2a values alone do not constitute a complete Agent Card. Only capabilities with advertise: true MAY be mapped to public A2A skills. The runtime MUST build required A2A fields (including supported interfaces) according to the referenced A2A version and MUST validate the resulting card against A2A's own schema. A2A fields and signing semantics remain authoritative in A2A, not BRICK. BRICK does not claim to implement A2A task processing or authorization merely by producing a card. 9. Security and Privacy Considerations An agent definition can reference unsafe code, prompt-injection content, sensitive MCP endpoints, and internal information. Consumers MUST treat fetched instructions, skills, tool outputs, and external agent claims as lower-trust input. They MUST NOT allow such input to modify privileges or override application policy. Sharaf Expires 28 April 2027 [Page 5] Internet-Draft BRICK Core October 2026 A public A2A Agent Card MUST NOT contain private instructions, internal MCP server addresses, credentials, tokens, or user data from the BRICK manifest. Connection credentials MUST be handled by the runtime's secret and authorization facilities. Content digest checks MAY help identify changes to referenced resources, but digests alone do not confer trust or authorization. Deployment-specific policies, cross-domain delegation, signed-card verification, provenance, and discovery trust frameworks are important future extension topics but are not a prerequisite of this core format. 10. Conformance and Extensibility A Manifest Validator conforms if it validates the JSON Schema and the reference rules in Section 4, rejects malformed or ambiguous tool bindings, and identifies unknown unsupported extension requirements. A Runtime Adapter conforms if it can load a valid core manifest, report unsupported declared requirements, and enforce the allowlisted MCP bindings for every invoked capability. It MUST NOT claim portable behavioral equivalence across different models or runtimes. An A2A Projection Adapter conforms if it additionally generates a valid Agent Card for the selected A2A version, without disclosure of private manifest fields. Future protocol profiles MUST remain optional and MUST NOT change the meaning of the Core agent, capabilities, instructions, or skills objects without a declared BRICK major-version change. 11. IANA Considerations This document requests no IANA registrations. 12. References Normative: RFC 2119; RFC 8174; JSON Schema Draft 2020-12; Model Context Protocol Specification (2026-07-28); A2A Protocol Specification v1.0; Agent Skills Specification. Informative: AGENTS.md convention; draft-nederveld-adl (Agent Definition Language, expired Internet-Draft); Google Agent Development Kit documentation. References and stable URLs require final xml2rfc bibliographic review before submission. Sharaf Expires 28 April 2027 [Page 6] Internet-Draft BRICK Core October 2026 Appendix A. Example BRICK Core Manifest { "brickVersion": "0.5", "agent": { "id": "https://agents.example.org/customer-support", "name": "Customer Support", "description": "Answers subscription questions and checks channel availability", "version": "1.0.0" }, "goals": [ "Resolve subscription support questions" ], "instructions": [ { "id": "project-guidance", "uri": "./AGENTS.md" } ], "skills": [ { "id": "subscription-help", "uri": "./skills/subscription-help/SKILL.md" } ], "mcpServers": [ { "id": "billing", "transport": "streamable-http", "endpoint": "https://billing.example.org/mcp", "allowedTools": [ "lookup_subscription" ] }, { "id": "catalog", "transport": "streamable-http", "endpoint": "https://catalog.example.org/mcp", "allowedTools": [ "find_channel" ] } ], "capabilities": [ { "id": "subscription-help", "description": "Check a subscription and find channels", "inputs": [ Sharaf Expires 28 April 2027 [Page 7] Internet-Draft BRICK Core October 2026 "customer_reference", "channel_name" ], "outputs": [ "availability_status" ], "skillRefs": [ "subscription-help" ], "toolRefs": [ "billing:lookup_subscription", "catalog:find_channel" ], "advertise": true } ], "a2a": { "enabled": true, "endpoint": "https://agents.example.org/a2a", "protocolVersion": "1.0" } } Author's Address Sam Sharaf Independent Email: samuel.sharaf@gmail.com Sharaf Expires 28 April 2027 [Page 8]