Agent Intent Frame 0.1

1Conformance

Bold words have the meanings from RFC 2119. Must shows a requirement. Should shows a recommendation. May shows an option. Text that is not bold gives help only. It is not a requirement.

A frame is a JSON object. A sender makes frames. A receiver accepts frames for a capability that it supplies. A runtime is the code between the sender and the receiver. The runtime applies the constraints, calls the model, and validates the result.

The sender and the receiver may be the same process. This does not change the requirements.

2Frame types

There are three frame types. One exchange has one request frame. The receiver then sends one result frame or one refusal frame. It does not send more than one.

flowchart LR
    RQ["request<br/>sender → receiver"] --> RT{"Admissible?"}
    RT -- yes --> RS["result<br/>receiver → sender"]
    RT -- no --> RF["refusal<br/>receiver → sender"]
    class RQ context
    class RT check
    class RF refusal
    class RS ok

A receiver must not send a result frame if a check did not pass. If the receiver cannot satisfy the criteria in the permitted number of attempts, it must send a refusal frame. So a result frame always shows that all the criteria passed.

3Request frame

The table gives the top-level fields of a request frame. The consumer column shows the layer that reads each field. This column is a requirement in one direction only. The runtime must not put a field into the prompt if the column does not show prompt.

3.1 Context and artifacts

The context.artifacts field is an array of references. It does not contain the documents. Each entry has a type and an id. The runtime gets the document from an artifact store before it makes the prompt.

A sender should not put a document into a frame. The runtime writes each frame to a log. It also keeps each frame for a replay. So the log and the replay contain the document too. A reference keeps the frame small. It also keeps private data out of the log.

4Intent types

The intent_type field is a closed enum. A runtime must get its settings from this field only. It must not read the prompt to find the type of the request. If you add a value, you must put your own prefix in front of it. An example is x-acme.reconcile. A prefix prevents a clash with a future standard value.

flowchart TD
    F{"intent_type"} -- request --> A["Produce work<br/>capable model · sampling temperature<br/>read tools permitted"]
    F -- verify --> B["Check work against a contract<br/>independent model · temperature 0<br/>no tools · strict validation"]
    F -- critique --> C["Improve work without replacing it<br/>independent model · read-only tools"]
    F -- inform --> E["Deliver information, no result expected<br/>may carry side-effecting tools<br/>if the capability is privileged"]
    class F route
    class A model
    class B,C check
    class E orchestrate

A receiver must refuse a frame if it does not accept the intent_type of that frame. It gives a refusal code of its own.

5Constraints

Each field in constraints is a maximum value that the sender asks for. The sender does not control the value. A runtime must decrease each value to its own policy limit. If a frame asks for more than the policy limit, the runtime must refuse the frame.

Do not decrease the value without a message. The sender must learn that its terms are not acceptable.

6Acceptance criteria

Acceptance criteria must be checks that a computer can do. They must not be sentences. A computer cannot check "contains a clear recommendation". A computer can check must_include_sections(["Recommended Action"]). A criterion is an object.

A criterion has an id, a check that gives the kind, and an args object. It can also have an advertise_to_model flag. The default value of the flag is true.

{
  "id": "c3",
  "check": "must_exclude_patterns",
  "args": { "patterns": ["email", "phone"], "label": "personal contact details" },
  "advertise_to_model": false
}

A runtime must supply these kinds of check:

6.1 Withheld criteria

If advertise_to_model is false, the prompt builder does not put the criterion into the prompt. The validator applies the criterion to the result. There are two conditions for this flag. A sender should use the flag in both conditions:

• The model cannot apply the check to itself. Usually the source document contains the data that the check forbids. So the model must agree to obey. This is not a control.
• The model can satisfy the check with its tone. The min_confidence check is the usual example. If you tell a model the limit, the model writes with more confidence. It does not give more evidence.

A frame with an empty acceptance_criteria array does not give a definition of a good result. A runtime should refuse this frame with the code UNENFORCEABLE_CONTRACT. Do not accept work that you cannot evaluate.

7Result frame

A receiver sends a result frame only if all the acceptance criteria passed.

8Refusal frame

A refusal frame has a refused_at field. This field gives the layer that stopped the work. The value is important to the caller. A refusal at admission shows that the frame was not acceptable. The sender must change the frame. A refusal at validation shows that the frame was correct.

The capability could not satisfy the criteria. The caller must do a different thing for each value. So the two values are not one general failure code.

flowchart LR
    A["Frame arrives"] --> B{"Admit?"}
    B -- fails --> R1["refused_at: admission<br/>status: refused<br/>0 attempts · $0 spent<br/>the sender must change the frame"]
    B -- passes --> C["Model invoked"]
    C --> D{"Passed?"}
    D -- passes --> OK["result<br/>status: fulfilled"]
    D -- "fails after retries" --> R2["refused_at: validation<br/>status: failed<br/>the frame was fine;<br/>the work was not achievable"]
    C -- "cost or deadline exhausted" --> R3["refused_at: budget<br/>status: failed"]
    class A context
    class B enforce
    class C model
    class D check
    class R1,R2,R3 refusal
    class OK ok

8.1 Refusal codes

Each violation has a code, a section, and a detail. The section gives the part of the frame that caused the violation. The detail text is for a person. The codes do not change between versions. The detail text can change. A client must not parse the detail text.

A receiver can also refuse a frame for its own reasons. It knows which capabilities it supplies, which intent types it accepts, and which inputs it needs. It uses codes of its own for these conditions. This standard does not give them, because they are local to one receiver.

9Discovery

Discovery is out of scope. This standard does not tell a caller how to find a receiver. It does not give a document format. It does not reserve a path.

This is the same rule as the rule for transport. AIF gives the terms of one request. It does not give the network around that request.

Use a mechanism that you have already. If you use A2A, declare each capability as an A2A Skill in your Agent Card. Give the Skill the same name as the capability. Then a caller can find the receiver, and the frame gives the terms.

10Versioning

A frame gives its version as MAJOR.MINOR. If you add an optional field, the change is minor. These changes are major: you add a required field, or you remove a field. These changes are also major: you decrease the values of an enum, or you give a field a new definition.

A receiver for major version N must accept all the minor versions of N. If it finds a field that it does not know, it must ignore that field. It must not refuse the frame. If the major version is not known, the receiver must refuse the frame with the code UNSUPPORTED_VERSION. Do not try to use the parts that you know. A frame that you understand only in part is more dangerous than a refusal.

11Conformance levels

At level L2 this standard gives the results in this document. Level L1 only puts the prompt into fields. The runtime does not apply the constraints at level L1.

AMinimal valid frame

{
  "version": "0.1",
  "intent_type": "request",
  "capability": "research.summarize",
  "goal": { "objective": "Summarise incident 4471 for the executive committee." },
  "context": { "conversation_id": "rel-review-q3" },
  "expected_output": {
    "type": "bullet_summary",
    "sections": ["Customer Impact", "Top Risks", "Recommended Action"],
    "acceptance_criteria": [
      { "id": "c1", "check": "max_tokens", "args": { "limit": 300 } },
      { "id": "c2", "check": "must_include_sections",
        "args": { "sections": ["Recommended Action"] } }
    ]
  },
  "metadata": { "trace_id": "trace-8f21" }
}

BFull example

This is the same task with all the optional sections. Only these fields go to the model: goal, context.background, inputs, reasoning.analysis_framework, expected_output.type, expected_output.sections, and the criteria with the advertise flag. Code reads the other fields.

{
  "version": "0.1",
  "intent_type": "request",
  "capability": "research.summarize",
  "goal": {
    "objective": "Summarise incident 4471 for the executive committee.",
    "business_reason": "Quarterly reliability review, board pre-read.",
    "priority": "high"
  },
  "context": {
    "conversation_id": "rel-review-q3",
    "parent_turn": "turn-07",
    "background": "Committee has 90 seconds of attention for each incident.",
    "artifacts": [
      { "type": "incident_report", "id": "incident-4471" },
      { "type": "policy", "id": "postmortem-policy-v3" }
    ]
  },
  "inputs": { "audience": "executive committee", "region": "EU-C" },
  "constraints": {
    "deadline_seconds": 90,
    "cost": { "maximum_usd": 0.08 },
    "llm": { "maximum_tokens": 800, "temperature": 0.2 },
    "tooling": { "allowed": ["knowledge.search"], "disallowed": ["email.send"] },
    "security": { "allow_pii": false, "classification": "Internal" }
  },
  "reasoning": {
    "analysis_framework": [
      "Establish customer impact",
      "Rank contributing factors by recurrence risk",
      "Name one owning team and one funded action"
    ],
    "confidence_threshold": 0.75,
    "require_evidence": true
  },
  "expected_output": {
    "type": "bullet_summary",
    "sections": ["Customer Impact", "Top Risks", "Recommended Action"],
    "acceptance_criteria": [
      { "id": "c1", "check": "max_tokens", "args": { "limit": 300 } },
      { "id": "c2", "check": "must_include_sections",
        "args": { "sections": ["Customer Impact", "Top Risks", "Recommended Action"] } },
      { "id": "c3", "check": "must_exclude_patterns", "advertise_to_model": false,
        "args": { "patterns": ["email", "phone"], "label": "personal contact details" } },
      { "id": "c4", "check": "min_confidence", "advertise_to_model": false,
        "args": { "threshold": 0.75 } }
    ]
  },
  "quality": { "review_required": true, "reviewers": ["qa.verify", "comms.notify"] },
  "failure_policy": { "retry_attempts": 2,
                      "on_failure": ["NotifyPlanner", "EscalateToHuman"] },
  "handoff": { "possible_followups": ["comms.notify"] },
  "metadata": { "schema_id": "aif/0.1", "trace_id": "trace-8f21",
                "tags": ["reliability", "exec"] }
}

Implementation guide → · Python library →