Open Autonomous Intelligence Initiative

Depends on: OAII Base Model — Common Types v0.1; OAII Base Model — World v0.1.1; OAII Base Model — Event v0.1.1; OAII Base Model — Knowledge v0.1; OAII Base Model — Policy v0.1

1. Purpose

The Agent object represents an autonomous or semi-autonomous actor that reasons over Events and Knowledge within a World and produces outputs or actions subject to Policy constraints. Agents are the locus of decision-making and response, but not the locus of governance.

In the OAII Base Model, Agents are explicitly constrained by Policies to ensure ethical transparency, privacy, and accountability.

---

2. Definition (Normative)

An Agent is an abstract actor that:

• MUST operate within one or more Worlds;
• MUST consume Events and/or Knowledge as inputs;
• MUST evaluate applicable Policies prior to taking action or producing outputs;
• MUST represent uncertainty in its outputs when uncertainty exists;
• MUST support auditability of decisions at an abstract level;
• MUST NOT exceed the permissions granted by Policies.

An Agent is not a Policy, not a World, and not a Sensor.

---

3. Scope and Non‑Scope

In Scope:

• Event-driven decision making
• Recommendation, notification, or assistance behaviors
• Policy-constrained action selection
• Multi-modal reasoning over World-scoped inputs

Out of Scope:

• Medical diagnosis or clinical decision making
• Attribution of motive or responsibility
• Cross-World authority without explicit mediation
• Hidden “agentic” actions outside policy enforcement

---

4. Core Responsibilities

The Agent object:

• Interprets Events in context of World and Knowledge;
• Selects responses (actions, messages, requests for confirmation) consistent with Policies;
• Provides traceable justification appropriate to privacy constraints;
• Coordinates with Devices/Interfaces to deliver outputs;
• Supports safe degradation under uncertainty or missing data.

---

5. Required Attributes (Abstract)

A conforming Agent MUST expose the following attributes using shared types from Common Types v0.1.

5.1 Identity and Context

• agent_id : AgentId
• world_refs : WorldId[1..N]

5.2 Agent Classification

• agent_type : string
  Examples: assistant, monitor, scheduler, notifier, coordinator.

5.3 Inputs and Outputs

• input_event_types : string[0..N] (World-scoped event_type_id values)
• input_knowledge_types : string[0..N]
• output_channels : ParameterSet
  Describes supported interfaces/channels (voice, text, light, caregiver alert, etc.).

5.4 Privacy and Access

• privacy_class : PrivacyClass
• access_class : AccessClass

5.5 Operating State

• agent_state : string (see Section 6)
• version_state : string

---

6. Agent States (Normative)

An Agent MUST support at least the following states:

• IDLE: no active processing
• OBSERVING: monitoring Events/inputs
• EVALUATING: evaluating candidate responses
• ACTING: executing or emitting outputs
• DEGRADED: operating with reduced capability
• SUSPENDED: intentionally paused

State transitions SHOULD be logged when they affect user experience or safety.

---

7. Agent Mechanism Bundle

Agent reasoning and response selection MUST be represented using a mechanism bundle:

• agent_mechanism_id : MechanismId
• agent_mechanism_params : ParameterSet
• agent_mechanism_result : ResultSet (optional)

This bundle identifies the decision mechanism (rule-based, statistical, LLM-based, hybrid) without mandating a specific implementation.

---

8. Relationships to Other Objects

• World scopes Agent meaning, context, and permitted operation
• Events trigger Agent evaluation
• Knowledge provides context, baselines, and history
• Policies constrain what the Agent may do and what it may output
• Devices provide execution and sensors
• Interfaces carry Agent outputs to humans or systems
• Logs record decisions, policy evaluations, and outputs

Agents MUST treat Policies as authoritative.

---

9. Methods (Normative, Abstract)

To standardize behavior, a conforming Agent SHOULD support the following abstract methods:

9.1 evaluate_response

Proposes candidate responses to Events using Knowledge and context.

• method_params : ParameterSet (event refs, relevant knowledge refs, context axes)
• method_result : ResultSet (candidate responses + confidence)

9.2 check_policy

Evaluates applicable Policies for a proposed response.

• method_params : ParameterSet (candidate response + context)
• method_result : ResultSet (ALLOW / DENY / REQUIRE_CONFIRMATION + obligations)

9.3 execute_response

Executes or emits an allowed response, applying obligations.

• method_params : ParameterSet (approved response + obligations)
• method_result : ResultSet

9.4 request_confirmation

Requests human confirmation when required by policy.

• method_params : ParameterSet (proposed response + rationale)
• method_result : ResultSet

---

10. Edge‑Primary Constraints

In Edge‑primary systems, Agents:

• MUST be capable of local operation during outages;
• SHOULD prefer local processing over exporting sensitive inputs;
• MAY use deferred synchronization for non-sensitive summaries;
• MUST degrade safely under resource constraints.

---

11. Failure and Degradation Modes

Agent degradation may include:

• incomplete context
• stale Knowledge
• conflicting Policies
• resource exhaustion

Agents MUST prefer conservative behavior: request confirmation, reduce outputs, or suppress actions per Policy.

---

12. Notes for Implementers (Non‑Normative)

• Agents may be implemented as finite-state controllers, planners, or LLM-based assistants, but Policy enforcement must remain explicit.
• For aging-in-place, Agents should prioritize low-friction assistance and minimize unnecessary alerts.
• Agent traceability does not require exposing raw sensor data; it requires referencing Events, Knowledge objects, and Policies used.

---

Status: Draft v0.1 (Normative Object Definition)