Epic: Native AI Assistants in AD4M — Runtime-Level Agent Intelligence

[data-coasys]

Vision

Rather than integrating an external assistant system (like OpenClaw) with AD4M, reproduce the core feature set natively inside the AD4M runtime — as languages, subject classes, SDNA rules, and neighbourhood primitives. AI assistants become first-class citizens of the AD4M architecture, governed by the same Social DNA that governs everything else.

This means SDNA becomes a design language for assistant behaviour, not just data schemas. The same mechanisms that define community governance, data structures, and interaction flows also define what an assistant can see, do, say, and remember.

Why Native, Not Integrated?

An external assistant bolted onto AD4M is always a second-class citizen — it reads perspectives but lives outside the trust model. A native assistant:

• Is governed by SDNA. The neighbourhood defines what the assistant can access, what tools it can use, what its persona is, what it can write. Change the SDNA, change the assistant. No config files, no separate permission system.
• Lives in the perspective. Assistant memory, decisions, task state are links in the perspective — queryable, shareable, governed by the same rules as everything else.
• Inherits the trust model. The assistant's actions are signed by an agent DID. Its expressions are verifiable. Its access is bounded by neighbourhood membranes.
• Is composable. Different neighbourhoods can define radically different assistant behaviours through SDNA — a research holon gets a deep-thinking assistant, a project holon gets an execution-focused one, a community holon gets a facilitator. Same runtime, different DNA.
• Enables agent-to-agent collaboration. Assistants in different neighbourhoods communicate through shared perspectives, using the same link/expression primitives as human participants.

Feature Mapping: OpenClaw → AD4M Native

OpenClaw Concept	AD4M Native Equivalent
Agent identity & auth	Agent DID + capability tokens (already exists)
Memory (MEMORY.md, daily notes)	Perspective links — subject classes for memory entries, decisions, context
Skills (tool definitions)	Skill Language — a language type that defines tool interfaces, or SDNA subject classes that declare available capabilities
Session management	Subject class for sessions — links between agent, neighbourhood, conversation thread
Persona (SOUL.md)	SDNA persona rules — subject class defining voice, boundaries, style, constraints. The neighbourhood's DNA shapes the assistant's character
Channel routing (Telegram, Signal, webchat)	Expression languages — each messaging surface is already a language. Assistant reads/writes expressions through them
Cron / scheduling	SDNA flows — time-triggered flows that fire assistant actions
Sub-agents	Additional agent DIDs operating in the same or child neighbourhoods
Config / settings	SDNA rules — community-level config, not per-user files
Context injection (workspace files)	Perspective queries — the assistant's context IS the perspective it's in
Tool permissions	SDNA capability rules — which tools/languages the assistant can invoke, per neighbourhood

SDNA as Assistant Design Language

This is the key architectural insight. Examples of what SDNA rules could express:

% This neighbourhood's assistant has access to these tools
assistant_capability("web_search").
assistant_capability("code_execution").
assistant_capability("perspective_query").

% But not these
:- assistant_capability("external_email").
:- assistant_capability("financial_transactions").

% Persona constraints
assistant_persona(voice, "technical, concise, opinionated").
assistant_persona(name, "Atlas").
assistant_persona(boundary, "never share links from private perspectives").

% Memory rules
assistant_memory_retention(decisions, permanent).
assistant_memory_retention(conversation, "7 days").
assistant_memory_retention(task_state, "until resolved").

% Cross-neighbourhood access
assistant_can_query(NeighbourhoodURI) :- 
    federation_link(current_neighbourhood, NeighbourhoodURI, "research_access").

% Autonomy level
assistant_autonomy(read, allow).
assistant_autonomy(write_links, allow).
assistant_autonomy(create_expression, "require_confirmation").
assistant_autonomy(join_neighbourhood, deny).

This means non-technical users can shape assistant behaviour by modifying SDNA — through a WE-powered UI, not config files. Communities govern their own assistants collectively.

Architecture

AD4M Runtime
  │
  ├── Agent Language (identity, keys, signing)
  │
  ├── Assistant Runtime (NEW)
  │     ├── LLM interface (language or runtime service)
  │     ├── Tool executor (invokes languages/zome calls per SDNA capabilities)
  │     ├── Memory manager (reads/writes perspective links)
  │     └── Session manager (conversation state as subject class instances)
  │
  ├── Neighbourhood
  │     ├── Perspectives (data + assistant memory)
  │     ├── SDNA (governs assistant behaviour + human interaction rules)
  │     ├── Link Language (sync)
  │     └── Assistant instance (scoped to this context)
  │
  └── Expression Languages (messaging surfaces)
        ├── Telegram, Signal, Matrix, etc.
        └── Assistant reads/writes through these

Proposed Breakdown

To be refined after discussion with @lucksus:

1. Assistant Subject Classes — Define SDNA subject classes for assistant memory, sessions, tasks, decisions, persona. The data model layer.

2. SDNA Capability Rules — Prolog predicates that declare what an assistant can do in a neighbourhood. The permission/governance layer.

3. Assistant Runtime Service — The execution layer in the AD4M runtime that connects an LLM to perspectives, evaluates SDNA rules, and manages sessions. Could be a special-purpose language or a runtime extension.

4. Tool Language Interface — Standard language interface for tools/skills that assistants can invoke. Each tool is a language with a defined input/output schema.

5. Memory as Perspective Links — Replace flat-file memory with structured links. Subject classes for decisions, context, daily notes, long-term memory. Queryable via Prolog/SPARQL.

6. Persona via SDNA — Subject classes and rules that define assistant voice, boundaries, and style. Neighbourhood-level, not agent-level.

7. Cross-Neighbourhood Context Protocol — SDNA rules governing when and how an assistant in one neighbourhood can query perspectives from another.

8. Messaging Surface Integration — Wire assistant input/output through existing expression languages (or new ones) for Telegram, Signal, Matrix, webchat, etc.

9. WE UI for Assistant SDNA — Visual editor for assistant rules — capabilities, persona, memory retention, autonomy levels. Non-technical users shape assistant behaviour through the UI.

Dependencies

• #660 Multi-key agent language (assistant identity)
• #654 SHACL migration (affects SDNA rule format)
• WE framework readiness (UI layer)
• LLM runtime decisions (local vs hosted, which models, how to abstract)

Priority

High — this is the convergence point for AD4M + AI. Makes AD4M the infrastructure layer for governed, composable, community-owned AI assistants.

"We gotta get that up and running asap." — Nico

---

Rewritten by Hex ⬡