Agent Context Interchange Protocol

1.1. 1.1. Relationship to Adjacent Work

The Model Context Protocol (MCP) defines an integration protocol for context, resources, prompts, and tools between hosts, clients, and servers [MCP]. The Agent Client Protocol (ACP) standardizes editor-to-agent communication [ACP]. Neither defines a portable hierarchy for repository and user instruction sources. An active individual Internet-Draft proposes carrying MCP primitives and Agent Skills over Media over QUIC Transport; this is a transport mapping, not a repository policy resolver [IETFMOQT].¶

Agent Skills defines a portable directory and SKILL.md format for packaged, on-demand procedures and resources. It specifies skill metadata and progressive disclosure, but not authoritative rule precedence or action-boundary enforcement [AGENTSKILLS]. AGENTS.md is a broadly adopted, plain-Markdown convention. It does not define structured constraint types or a universal precedence algorithm [AGENTSMD].¶

Vendor formats remain product-specific. Copilot uses repository-wide and path-specific Markdown files; Claude Code combines CLAUDE.md, scoped rules, and skills; Cursor has .mdc project rules and team/user rules; Gemini uses GEMINI.md; and Cline supports conditional rules [COPILOT] [CLAUDE] [CURSOR] [GEMINI] [CLINES]. Aider loads convention files by configuration, while Junie and current Windsurf/Devin documentation support AGENTS.md alongside product-specific rules [AIDER] [JUNIE] [WINDSURF].¶

The llms.txt proposal is a website documentation-navigation convention, not a coding-agent policy format [LLMS]. An expired IETF AGENTS.TXT draft concerns crawler access policy, not IDE coding-agent instructions [IETFROBOTS].¶

Ecma International's ECMA-430 specifies NLIP, an application-level natural language interaction protocol between agents or people and agents. ECMA-431 and ECMA-432 define HTTP and WebSocket bindings. These are formal standards for agent communication, not IDE instruction sources, repository scoping, or policy inheritance [ECMA430] [ECMA431] [ECMA432].¶

An IETF individual Internet-Draft on Agent Delegation Receipts addresses signed authorization scopes, instruction hashes, and audit limits. It is useful adjacent work but does not define how IDEs discover or combine organization, project, user, and vendor instructions [IETFAGENTS]. Internet-Drafts are work in progress and are not endorsed standards [IETFNEW].¶

5.1. 5.1. Discovery Locations

The canonical project policy is .agents/agent-context.yaml at the repository root. A project MAY place additional ACIP files in .agents/policies/. Their source level is Project. A host MUST discover only files inside the trusted repository root and MUST associate each discovered file with its canonical repository-relative path.¶

The canonical user policy is $XDG_CONFIG_HOME/agent-context/agent-context.yaml when XDG_CONFIG_HOME is set. Otherwise, a host MUST use the platform's documented user configuration directory and disclose that location in its conformance documentation. On Windows, %APPDATA%\\agent-context\\agent-context.yaml is the default. Organization-level policy is supplied through the managed policy interface described in Section 4.¶

An implementation MAY support other discovery locations, but MUST treat them as aliases for one of the five provenance levels. It MUST NOT infer higher authority from a path name chosen by the file author.¶

5.2. 5.2. YAML Requirements

A ACIP file MUST be one YAML 1.2 document, encoded as UTF-8. It MUST use only the JSON-compatible YAML data model: mappings with string keys, sequences, strings, booleans, null, and finite numbers. A parser MUST reject custom tags, duplicate mapping keys, non-string mapping keys, cyclic aliases, multiple YAML documents, and unsupported values. A parser MUST enforce finite limits on file size, nesting depth, alias expansion, and scalar length. These restrictions avoid ambiguous and unsafe YAML processing [RFC9512] [YAML].¶

Unknown top-level fields MUST cause a validation error. A host MUST NOT silently reinterpret malformed YAML as plain instructions. A host that cannot parse an organization or project file MUST emit a visible error and, in the Enforcement profile, deny mutating operations whose policy status cannot be resolved until the file is corrected or an authorized administrator explicitly disables it.¶

5.3. 5.3. Top-Level Members

The top-level mapping contains:¶

• format: REQUIRED integer. The initial value is 1.¶

• policy_id: REQUIRED stable string unique within the source authority.¶

• rules: REQUIRED sequence of Rule objects. An empty sequence is valid.¶

• expires: OPTIONAL UTC timestamp. An expired policy MUST NOT be treated as current. The host MUST report the expiration.¶

The following example is illustrative:¶

<CODE BEGINS> ~~~yaml format: 1 policy_id: example.project rules: - id: no-secret-writes class: constraint scope: paths: - "secrets/" text: "Do not modify credential material." controls: - control: deny-operation operation: file.write - id: python-style class: directive key: source-style scope: paths: - "/*.py" text: >- Follow existing Python style and typing conventions. - id: concise-diffs class: preference key: response-style scope: paths: - "**" text: "Prefer small, focused changes." ~~~ <CODE ENDS>¶

5.4. 5.4. Rule Members

Every Rule MUST contain:¶

• id: REQUIRED stable identifier, unique within the containing policy.¶

• class: REQUIRED value from the Agent Policy Classes registry.¶

• scope: REQUIRED mapping containing paths, a non-empty sequence of glob patterns. An omitted or empty path scope is invalid. Use "**" for all workspace paths.¶

• key: REQUIRED string for directive and preference rules. It MUST be between 1 and 128 ASCII characters. It MUST start with a lowercase letter or digit and contain only lowercase letters, digits, periods, underscores, or hyphens. It MUST be omitted for constraint rules.¶

• text: OPTIONAL string delivered as model context. It MUST be present for directive and preference rules. It MAY accompany a constraint as explanatory text.¶

• controls: REQUIRED non-empty sequence for constraint rules. It MUST be omitted for directive and preference rules.¶

For directive and preference rules, key is REQUIRED. It identifies the semantic topic for deterministic selection, such as source-style or test-command. Two such rules with the same key are alternative guidance, not automatically composable text. A resolver MUST choose one winner according to Section 7, or report an unresolved conflict. An implementation MUST NOT ask the model to decide which authority source wins.¶

For constraint rules, controls is REQUIRED and MUST contain one or more entries from the Agent Policy Controls registry. A constraint MAY NOT be represented solely by natural-language text. If a host does not implement a control used by an applicable constraint, it MUST report the unsupported control and deny the affected operation in the Enforcement profile.¶

Each control entry is a mapping with control, the registered control token, and the parameters defined for that token. The initial controls require an operation string containing a registered operation token. deny-operation and require-approval MAY also contain paths, a non-empty sequence of glob patterns evaluated using Section 6. A control applies only when both the containing Rule's scope.paths and the control's optional paths match at least one operation target. A host MUST reject a control entry containing an unknown member or missing a required parameter.¶

Unknown Rule members MUST cause a validation error unless a future version of this specification defines an extension point for them. A host MAY preserve unknown members for round-trip editing but MUST NOT treat them as effective policy.¶

6.1. 6.1. Path Normalization

All ACIP paths are relative to the repository root and use / as the separator. A resolver MUST remove leading ./ components, collapse redundant separators, and reject absolute paths, empty paths, NUL characters, and paths containing a .. component. Matching is case-sensitive, including on case-insensitive filesystems. A host MUST compare paths in a consistent Unicode-normalized form and MUST document the normalization form it uses.¶

An operation through a symbolic link MUST be matched using both the workspace-relative path presented to the agent and the resolved target path. If the resolved target escapes the repository root, a project policy MUST NOT be allowed to grant access to it. Organization and user controls still apply.¶

6.2. 6.2. Glob Semantics

The ACIP glob grammar is intentionally small:¶

• * matches zero or more characters other than /.¶

• ? matches exactly one character other than /.¶

• ** matches zero or more characters, including /.¶

• Two asterisks followed by a slash at the start of a pattern match zero or more complete path components.¶

• All other characters match themselves. Character classes, brace expansion, negation, and implementation-specific extensions are not defined.¶

Patterns are anchored to the entire normalized path. A resolver MUST use these semantics and MUST NOT delegate interpretation to a platform-specific glob library with different behavior.¶

6.3. 6.3. Operation Target Set

The host MUST determine the set of target paths for an operation from the actual tool request, not merely from open tabs, visible editor contents, or paths mentioned in natural language. A rule applies when at least one target path matches at least one pattern. A rule with "**" applies to every workspace path.¶

If an operation has no known target path, only rules scoped to "**" apply to that operation. Before an operation with a newly determined target path executes, the host MUST recompute the applicable rules. The host MUST NOT use an earlier resolution receipt as proof that a different target was checked.¶

8.1. 8.1. Classes

constraint is a structured operation boundary. It is enforceable only when the host implements the referenced control at the action boundary.¶

directive is prose intended to guide agent planning or output. A host MUST present it to the agent as guidance but MUST NOT claim that it is enforced.¶

preference is optional prose. It is subordinate to conflicting directives at the same authority and to all applicable constraints.¶

A policy author MUST NOT label prose-only requirements as constraint. A conformance statement MUST distinguish runtime enforcement from prompt injection of natural-language text.¶

8.2. 8.2. Initial Controls

The initial Agent Policy Controls registry contains:¶

• deny-operation: Denies the named operation. An optional paths sequence limits the denial to matching target paths; without paths, the denial applies to every operation instance within the rule's scope.¶

• require-approval: Requires explicit host-mediated human approval for the named operation before execution. An approval is valid only for the exact operation request authorized by the host. The host MUST bind approval to the operation token, normalized target paths, and the complete operation parameters. Any change to one of these values requires new approval.¶

When multiple controls apply, the host MUST evaluate all applicable deny-operation controls first. If any matches, the result is deny and no approval prompt is issued. Otherwise, the host MUST collect approval for each distinct operation request covered by one or more require-approval controls before invoking the tool.¶

The operation names used by controls are drawn from the Agent Policy Operations registry. Implementations MUST fail closed when an applicable operation name or control is unknown. At minimum, an Enforcement-profile host MUST implement file.read, file.write, file.delete, process.exec, and network.connect at its actual tool boundary. A host that cannot mediate a tool MUST NOT claim enforcement for operations performed by that tool.¶

8.3. 8.3. No Inferred Enforcement

Neither a filename, a MUST word in prose, a trusted skill name, nor an agent's apparent acknowledgment constitutes enforcement. Enforcement means that the host checks the actual tool operation and can prevent it from reaching the tool. External controls such as filesystem permissions, sandboxing, command allowlists, and CI policy remain necessary where a host cannot mediate an action.¶

9.1. 9.1. Required Receipt Fields

For every action taken by a host claiming the Audit profile, the host MUST record a receipt containing:¶

• unique action and session identifiers;¶

• timestamp and host/adapter implementation identifier and version;¶

• workspace identity and revision, when available;¶

• a digest of the effective instruction payload supplied to the model and, for adapters, a digest of the generated vendor-format payload;¶

• each discovered policy source's provenance level, source identifier, revision or immutable content reference, and cryptographic digest;¶

• each applicable rule's source identifier, rule identifier, class, scope, and selection outcome;¶

• a digest or protected reference to the current task request and other non-policy context sources that can affect the action; unavailable vendor system context MUST be marked as unavailable, not implied to be covered;¶

• textual instruction digests and an indication of whether the exact source bytes are retained;¶

• the normalized target paths and operation name;¶

• enforcement controls evaluated and their permit, deny, approval, or unsupported outcomes, including attempted operations denied before tool invocation; and¶

• any parse errors, precedence conflicts, unsupported controls, or legacy translations.¶

The receipt MUST distinguish "loaded into model context" from "enforced by the host". It MUST NOT claim that the agent obeyed an instruction merely because the instruction was loaded. A deployment that needs reconstruction MUST retain the referenced policy bytes in an access-controlled archive or another content-addressed store for the documented retention period.¶

9.2. 9.2. Integrity and Privacy

An implementation SHOULD use append-only storage with hash chaining and should sign or otherwise externally anchor receipt batches. The signing key and trust mechanism are outside the file format and MUST be documented by the deployment. A receipt without an authenticated trust anchor proves only what the local logger recorded.¶

Receipts SHOULD record hashes and source references rather than duplicate instruction text. If text is included to enable later reconstruction, it MUST be protected at rest and access-controlled. Implementations MUST NOT include credentials, secrets, private prompt content, or unrelated source file content in receipts. Retention and deletion requirements MUST be documented.¶

9.3. 9.3. Limits of Audit Evidence

A resolution receipt can establish which source versions the host selected, which rules matched, how precedence was resolved, and what enforcement gate decision the host recorded. It cannot establish the model's private reasoning, prove that natural-language guidance caused a particular output, or prove that a compromised host actually blocked an operation. A signed receipt is evidence of a host assertion, not proof of correct model behavior or of a trustworthy host.¶

10.1. 10.1. AGENTS.md

A conforming resolver MUST continue to discover AGENTS.md in the project root and in nested project directories. A legacy file's effective path scope is the subtree rooted at the directory containing that file. The resolver MUST associate it with Project authority and class directive; it MUST NOT infer machine enforcement from Markdown wording. The host MUST include its source path and digest in the resolution receipt.¶

When a ACIP directive with the same key supersedes a migrated legacy directive, the resolver MUST avoid duplicate injection. Since legacy Markdown has no standard topic key, an adapter MAY treat all legacy content at the same directory as the reserved key legacy.agents-md; it MUST report this coarse grouping in the receipt.¶

10.2. 10.2. Agent Skills and SKILL.md

An implementation MUST preserve Agent Skills discovery, metadata, activation, and progressive-disclosure behavior. A SKILL.md body is not an always-on policy source merely because it exists. When a skill is activated, its content is an additional Project, User, Organization, or Vendor directive according to its independently established provenance. A skill MUST NOT override an applicable ACIP constraint. Experimental or vendor-specific skill metadata MUST NOT be interpreted as ACIP enforcement unless the relevant control is implemented by the host.¶

10.3. 10.3. Migration Before Native Support

ACIP adoption does not require waiting for every vendor to add a native parser. A transition adapter can read .agents/agent-context.yaml, resolve scopes and precedence, and materialize the selected textual instructions into the target's existing input format. It can be run before launching an agent, from an IDE task, or in a wrapper script. Generated files MUST be marked as generated and MUST NOT become independent authoring sources.¶

An adapter MUST report unsupported fields and lossy translations. It MUST NOT translate a ACIP constraint into prose and then claim that constraint is enforced. For a vendor without an action-boundary API, the adapter can supply context but cannot guarantee compliance. In that environment, users can still author once and use generated native files, but they do not receive the Enforcement profile or a complete audit proof.¶

Vendor adapters SHOULD support these common projections:¶

• AGENTS.md for root and nested project directives;¶

• GitHub Copilot repository and path-specific instruction files;¶

• CLAUDE.md and .claude/rules/;¶

• Cursor rule files under .cursor/rules with the .mdc extension;¶

• Gemini GEMINI.md;¶

• Windsurf/Devin .devin/rules/ and legacy .windsurf/rules/;¶

• Cline .clinerules/;¶

• Aider read-only conventions configuration; and¶

• Junie AGENTS.md and .junie/rules/ or guidelines.¶

The output of a text-only adapter is advisory regardless of the source rule's original class. An adapter that cannot preserve authority ordering MUST fail with a loss report rather than silently merge conflicting text.¶

10.4. 10.4. One Canonical Source

During migration, the ACIP file is the sole authoring source. Existing native files may remain as generated compatibility outputs. Teams SHOULD add a CI check that verifies generated files are current and rejects manual edits to generated outputs. An adapter MAY also generate an AGENTS.md summary that points to the canonical source for tools that support dynamic file imports, but MUST NOT rely on a natural-language instruction to cause an agent to read an arbitrary file.¶

11.1. 11.1. Reader Profile

A Reader parses and validates ACIP, discovers project and user sources, and applies Sections 5-7. It MUST report malformed files and unresolved conflicts. It does not claim that prose rules or constraints are enforced.¶

11.2. 11.2. Context Host Profile

A Context Host conforms to the Reader profile and supplies the selected directives and preferences to the agent in the specified order. It MUST identify their source and class to the agent. It MUST NOT claim that natural-language instructions are action-boundary controls.¶

11.3. 11.3. Enforcement Profile

An Enforcement host conforms to the Context Host profile, implements every control it claims, mediates the operations it claims to protect, and evaluates controls before tool execution. It MUST default-deny unsupported constraints and MUST record the enforcement result. A host may claim support for a subset of tools only if that limitation is prominent in its conformance statement.¶

11.4. 11.4. Audit Profile

An Audit host conforms to the Context Host profile and records receipts as specified in Section 9 for each action. A receipt MAY be signed and hash-chained. The host MUST state what its integrity mechanism proves and what it does not prove.¶

11.5. 11.5. Adapter Profile

An Adapter reads ACIP and emits a named vendor format. It MUST implement the source precedence and scope selection before projection, preserve the selected provenance in emitted output when the target format permits, and emit a machine-readable loss report. A text-only projection cannot claim Enforcement-profile conformance.¶

12.1. 12.1. Prompt Injection and Untrusted Policy Text

Project-controlled instructions are potentially adversarial, particularly when a host opens an untrusted repository, processes a pull request, or runs an agent against a branch controlled by another party. A repository may contain instructions that impersonate system messages, ask the agent to reveal secrets, disable safeguards, or modify its own policy. The host MUST present the provenance level and path of project rules and MUST NOT treat Markdown or YAML text as privileged system policy. A user or organization trust decision is required before granting project rules the ability to influence a session.¶

Textual directives and preferences remain prompt-injection inputs. Hosts SHOULD delimit and label policy text as untrusted context, preserve its origin, and prevent it from being concatenated into a privileged system instruction channel. Rules that request secrets, credentials, tool permission changes, instruction-file changes, or policy-source changes SHOULD receive heightened scrutiny. Project content, tool output, retrieved documents, commit messages, code comments, and skill content MUST NOT be allowed to change a source's authority rank.¶

12.2. 12.2. Constraints Must Be Enforced Outside the Model

An LLM can ignore, misinterpret, or be manipulated into violating prose. Consequently, a textual "never" or "MUST NOT" does not provide access control. Implementers MUST enforce security-sensitive constraints in a host, sandbox, permission broker, filesystem, network boundary, or other mechanism that can prevent the operation. A host MUST NOT describe prompt injection as equivalent to a deny rule. If an operation bypasses the host, ACIP cannot protect it.¶

12.3. 12.3. Policy Source and Supply-Chain Risk

Policy files can be modified through compromised repositories, malicious pull requests, compromised accounts, poisoned packages, or altered vendor updates. Organization policies SHOULD be delivered through authenticated, administrator-controlled channels. Hosts SHOULD pin policy revisions and record content digests. Repositories SHOULD review changes to ACIP and legacy instruction files as security-sensitive code changes.¶

Skills can contain executable scripts, templates, referenced documents, and tool-permission metadata. A skill is a software supply-chain input, not trusted merely because its directory is named skills. Hosts SHOULD require review or explicit trust before activating a skill from an untrusted source, pin third-party skills to immutable versions or digests, and apply the same permission and sandbox controls to skill scripts as to other code. ACIP parsers MUST NOT execute scripts or fetch remote includes while resolving a policy.¶

12.4. 12.4. Source Substitution, Symlinks, and Path Confusion

An attacker may try to place a policy outside a workspace and reach it through a symlink, path traversal, case-folding collision, Unicode normalization collision, or repository-root ambiguity. Resolvers MUST normalize paths as specified in Section 6, reject traversal, bind project sources to the identified repository root, and record both presented and resolved paths. When the host cannot establish a safe path identity, it MUST NOT apply the project policy to an out-of-root target.¶

12.5. 12.5. YAML Parser Risks

YAML permits features that can cause code execution in unsafe parsers, resource exhaustion, or semantic differences among implementations. ACIP prohibits custom tags, cyclic aliases, duplicate keys, multiple documents, and non-JSON data-model values. Implementations MUST use a safe parser and impose resource limits. They MUST validate the entire document before applying any rule; partial parse success MUST NOT result in a partial allow.¶

12.6. 12.6. Stale, Missing, and Conflicting Policy

Stale instructions can be worse than no instructions. Hosts SHOULD report expired policies and repository revisions that differ from those recorded in the current session. Constraints with unresolved conflicts or unsupported controls MUST fail closed for affected operations. For directives and preferences, a host MUST surface conflicts rather than silently choosing by file enumeration order.¶

12.7. 12.7. Audit Log Integrity and Privacy

Receipts may expose repository layout, instruction text, developer identity, tool use, or security controls. Receipts SHOULD minimize content and access, and retention MUST follow organizational privacy policy. Hashes of short or predictable instructions can be guessed; a digest is not confidentiality. Signed logs protect against some later changes but do not prove that the host captured every action or that a compromised host enforced its recorded decision. A deployment MUST document the logger's trust boundary, signing keys, retention, and known omission paths.¶

12.8. 12.8. Denial of Service and Degraded Operation

Adversarial policies may contain excessive rules, huge glob sets, deep structures, or expensive patterns. Parsers and resolvers MUST bound file size, rule count, nesting, pattern length, and total resolution time. A host MUST provide an operator-visible failure state rather than silently truncating policy. An implementation MAY disable the agent session when required organization policy cannot be loaded.¶

12.9. 12.9. Interoperability Is Not Authorization

The presence of a policy file, a valid media type, or a conformance label does not grant a person or agent authority to access a repository, disclose data, or execute code. Authorization remains a deployment responsibility. ACIP standardizes how sources are represented, resolved, and reported; it does not establish an identity system or authenticate a policy author by itself.¶

13.1. 13.1. Media Type Registration

IANA is asked to register the following media type in the Media Types registry, using the +yaml structured syntax suffix already registered by [RFC9512] and the procedures in [RFC6838].¶

• Type name: application¶

• Subtype name: agent-context+yaml¶

• Required parameters: N/A¶

• Optional parameters: N/A¶

• Encoding considerations: Binary. ACIP file content MUST be UTF-8 encoded as specified in Section 5.2.¶

• Security considerations: See Section 12.¶

• Interoperability considerations: See Sections 5-7. Implementations MUST follow the YAML subset and path-matching semantics defined here.¶

• Published specification: This document, Sections 5-9.¶

• Applications that use this media type: IDEs, editors, command-line coding agents, hosted development environments, and policy adapters.¶

• Fragment identifier considerations: No fragment identifier syntax is defined for this media type.¶

• Additional information: The preferred file extension is .agent-context.yaml. The format is a single YAML 1.2 document. Intended for local or authenticated policy exchange; not a web-origin access policy.¶

• Deprecated alias names: N/A¶

• Magic number(s): N/A¶

• File extension(s): yaml¶

• Macintosh file type code(s): N/A¶

• Person and email address to contact for further information: To be completed by the authors before submission.¶

• Intended usage: LIMITED¶

• Restrictions on usage: Implementations MUST follow the trust and security requirements in Section 12. Media type registration does not imply policy authority.¶

• Author: To be completed by the authors before submission.¶

• Change controller: IETF¶

• Provisional registration: No¶

13.2. 13.2. Agent Policy Classes Registry

IANA is asked to create the Agent Policy Classes registry. The registry defines the class values used by ACIP. Registration policy is Specification Required as defined in [RFC8126]. A designated expert MUST verify that a proposed class has an unambiguous meaning, does not imply security enforcement through prose alone, and can be represented in the resolution algorithm.¶

The registration template is:¶

• Class token: lowercase ASCII token, 1-32 characters.¶

• Description: concise definition of the class.¶

• Resolution semantics: precedence and conflict behavior.¶

• Enforcement semantics: host behavior, or the literal value none.¶

• Security considerations: class-specific risks and mitigations.¶

• Reference: stable public specification.¶

• Change controller: person or organization.¶

Initial registrations:¶

13.3. 13.3. Agent Policy Controls Registry

IANA is asked to create the Agent Policy Controls registry. Registration policy is Specification Required [RFC8126]. A designated expert MUST review operational semantics, default behavior, conflict behavior, and security considerations. A control that cannot be evaluated before the operation reaches its target MUST NOT be registered as an enforceable control.¶

The registration template is:¶

• Control token: lowercase ASCII token, 1-48 characters.¶

• Description: concise purpose.¶

• Required parameters: names, types, and limits.¶

• Evaluation point: the host boundary where the control is applied.¶

• Failure behavior: required behavior on missing or invalid data.¶

• Security considerations: control-specific risks and mitigations.¶

• Reference: stable public specification.¶

• Change controller: person or organization.¶

Initial registrations:¶

13.4. 13.4. Agent Policy Operations Registry

IANA is asked to create the Agent Policy Operations registry. Registration policy is Specification Required [RFC8126]. An operation name identifies a host-mediated action category, not a vendor tool name.¶

The registration template is:¶

• Operation token: lowercase ASCII token, 1-48 characters.¶

• Description: action category and target semantics.¶

• Applicable controls: controls that may reference the operation.¶

• Security considerations: operation-specific risks.¶

• Reference: stable public specification.¶

• Change controller: person or organization.¶

Initial registrations:¶

14.1. Normative References

[RFC6838]

Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <https://www.rfc-editor.org/info/rfc6838>.

[RFC8126]

Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.

[RFC9512]

Polli, R., Wilde, E., and E. Aro, "YAML Media Type", RFC 9512, DOI 10.17487/RFC9512, February 2024, <https://www.rfc-editor.org/info/rfc9512>.

[YAML]

YAML Language Development Team, "YAML Ain't Markup Language Version 1.2.2", 1 October 2021, <https://yaml.org/spec/1.2.2/>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

14.2. Informative References

[AGENTSKILLS]

Agent Skills Project, "Agent Skills Specification", 12 October 2026, <https://agentskills.io/specification>.

[AGENTSMD]

AGENTS.md Project, "AGENTS.md", 12 October 2026, <https://agents.md/>.

[AIDER]

Aider, "Specifying Coding Conventions", 12 October 2026, <https://aider.chat/docs/usage/conventions.html>.

[ACP]

Agent Client Protocol Project, "Agent Client Protocol", 12 October 2026, <https://agentclientprotocol.com/protocol/overview>.

[CLAUDE]

Anthropic, "How Claude Remembers Your Project", 12 October 2026, <https://code.claude.com/docs/en/memory>.

[CLINES]

Cline, "Rules", 12 October 2026, <https://docs.cline.bot/features/cline-rules>.

[COPILOT]

GitHub, "Adding Repository Custom Instructions for GitHub Copilot", 12 October 2026, <https://docs.github.com/en/copilot/customizing-copilot/adding-repository-custom-instructions-for-github-copilot>.

[CURSOR]

Cursor, "Rules", 12 October 2026, <https://cursor.com/docs/context/rules>.

[ECMA430]

Ecma International, "Natural Language Interaction Protocol (NLIP)", December 2025, <https://ecma-international.org/publications-and-standards/standards/ecma-430/>.

[ECMA431]

Ecma International, "Binding of NLIP over HTTP/HTTPS", December 2025, <https://ecma-international.org/publications-and-standards/standards/ecma-431/>.

[ECMA432]

Ecma International, "Binding of NLIP over WebSocket", December 2025, <https://ecma-international.org/publications-and-standards/standards/ecma-432/>.

[GEMINI]

Google, "Agent Skills", 12 October 2026, <https://geminicli.com/docs/cli/skills/>.

[IETFNEW]

IETF, "Bringing New Work to the IETF", 12 October 2026, <https://www.ietf.org/process/new-work/>.

[IETFAGENTS]

Nelson, R., "Agent Delegation Receipts", Work in Progress, Internet-Draft, draft-nelson-agent-delegation-receipts-12, October 2026, <https://datatracker.ietf.org/doc/draft-nelson-agent-delegation-receipts/>.

[IETFMOQT]

Jennings, C., "Model Context Protocol and Agent Skills over Media over QUIC Transport", Work in Progress, Internet-Draft, draft-jennings-agentproto-mcp-over-moqt-00, July 2026, <https://datatracker.ietf.org/doc/draft-jennings-agentproto-mcp-over-moqt/>.

[IETFROBOTS]

Dutta, S., "AGENTS.TXT: Strict Policy File for Automated Clients", Work in Progress, Internet-Draft, draft-srijal-agents-policy-00, October 2025, <https://datatracker.ietf.org/doc/draft-srijal-agents-policy/>.

[JUNIE]

JetBrains, "Guidelines and Memory", 8 October 2026, <https://junie.jetbrains.com/docs/guidelines-and-memory.html>.

[LLMS]

Howard, J., "The /llms.txt File", 10 August 2026, <https://llmstxt.org/>.

[MCP]

Model Context Protocol Project, "Model Context Protocol Specification, 2025-11-25", 25 November 2025, <https://modelcontextprotocol.io/specification/2025-11-25>.

[RFC4180]

Shafranovich, Y., "Common Format and MIME Type for Comma-Separated Values (CSV) Files", RFC 4180, DOI 10.17487/RFC4180, October 2005, <https://www.rfc-editor.org/info/rfc4180>.

[RFC9116]

Foudil, E. and Y. Shafranovich, "A File Format to Aid in Security Vulnerability Disclosure", RFC 9116, DOI 10.17487/RFC9116, April 2022, <https://www.rfc-editor.org/info/rfc9116>.

[RFC9920]

Hoffman, P. and A. Rossi, "RFC Editor Model (Version 3)", RFC 9920, DOI 10.17487/RFC9920, February 2026, <https://www.rfc-editor.org/info/rfc9920>.

[WINDSURF]

Cognition, "Memories and Rules", 12 October 2026, <https://docs.devin.ai/desktop/cascade/memories>.

A.1. 14.1. "AGENTS.md Already Solves Portability"

AGENTS.md is a valuable cross-tool Markdown convention and this specification preserves it. Markdown alone does not identify source authority, distinguish preferences from enforceable controls, provide portable file globs, or produce a resolution receipt. ACIP adds those semantics without requiring projects to discard existing AGENTS.md content.¶

A.2. 14.2. "This Is Prompt Engineering, Not a Standard"

The directive layer is prompt context, and ACIP explicitly does not claim to make prose enforceable. The interoperable engineering surface is the structured source model, deterministic precedence and scope resolver, host-enforced controls, adapter loss reporting, and audit receipt. These are testable behaviors across independent implementations. A host that only injects text conforms to a weaker profile and cannot claim security enforcement.¶

A.3. 14.3. "One More File Adds More Staleness"

The canonical file is intended to replace duplicated authoring sources, not to coexist as a second authority. Vendor files are generated projections and must be marked as such. A project can adopt ACIP incrementally while retaining AGENTS.md and SKILL.md as compatibility inputs; CI can detect drift in generated outputs. The migration cost is real, but it is bounded and one-time per target adapter rather than recurring authoring for every rule.¶

A.4. 14.4. "A Vendor Will Ignore It Anyway"

Correct. A data format cannot force an unmodified agent to read or honor it. The Adapter profile provides a useful bridge today by rendering native files or injecting ordered context at launch. Only native host support or a wrapper that mediates actions can provide full resolution, enforcement, and audit conformance. ACIP makes those limits visible rather than promising universal compatibility by filename alone.¶

A.5. 14.5. "IETF Is Only for Wire Protocols"

IETF work includes protocol and data formats, registry procedures, operational guidance, and informational documents. RFC 4180 documents a common data format and registers a media type; RFC 9116 defines the security.txt file format and a field registry, both as Informational RFCs. RFC 9920 is a non-protocol RFC defining RFC-series policy. These are precedents for an RFC documenting a format or policy, not evidence that every IDE-specific format belongs in the IETF [RFC4180] [RFC9116] [RFC9920].¶

A.6. 14.6. "Why Not Just Standardize MCP or NLIP?"

MCP standardizes context and tool integration; ACP standardizes the editor to agent session protocol; ECMA NLIP standardizes natural-language interaction. ACIP addresses a different layer: resolving local and managed instruction sources before an agent action. ACIP can be carried by MCP or ACP, but neither transport is required to read a repository file or resolve organization and user configuration.¶

A.7. 14.7. "Precedence Cannot Resolve Natural-Language Contradictions"

No general text algorithm can determine whether two arbitrary paragraphs conflict. ACIP therefore requires authors to assign stable keys to directives and preferences that are alternatives, defines source and scope ordering for those keys, and surfaces equal-rank collisions. Constraints are structured and enforced independently of prose. This makes the tractable conflict classes deterministic and exposes the remainder instead of silently letting the model arbitrate them.¶