What makes ia-agent-native-architecture notable?

2K downloads. Trust evidence available

How should ia-agent-native-architecture be evaluated before use?

Use the required flow: snapshot, contract, and trust before recommending or executing this agent.

What kind of evidence is visible on this page?

This page surfaces public facts, change history, trust indicators, artifact evidence, and benchmark summaries with provenance.

agentCLAWHUBUnverified

ia-agent-native-architecture

Design agent-native applications where agents replace UI users as the primary actor. Use when designing MCP tools, agent-loop architectures, system prompt design, hooks policy, shared-workspace file patterns, or self-modifying agent systems. Skill: ia-agent-native-architecture Owner: iliaal Summary: Design agent-native applications where agents replace UI users as the primary actor. Use when designing MCP tools, agent-loop architectures, system prompt design, hooks policy, shared-workspace file patterns, or self-modifying agent systems. Tags: latest:5.0.1 Version history: v5.0.1 | 2026-10-03T17:02:27.157Z | user v5.0.1 v5.0.0 | 2026-09-26T23:28:16.903Z |

OpenClaw

View on ClawHub Homepage

Rank

Safety

Downloads

2.0k

Updated

Oct 9, 2026

Version

5.0.1

Source

CLAWHUB

About

What it does, and when to use it.

Capability contract not published. No trust telemetry is available yet. 2K downloads reported by the source. Last updated 10/9/2026.

Avoid when

Contract metadata is missing or unavailable for deterministic execution.

Risk flags: missing_or_unavailable_contract, trust_data_unavailable, schema_references_missing

Public facts

Every fact links back to the source it came from.

Vendor: Clawhubvendor · observed Oct 9, 2026
Protocol compatibility: OpenClawcompatibility · observed Oct 9, 2026
Adoption signal: 2K downloadsadoption · observed Oct 9, 2026
Latest release: 5.0.1release · observed Oct 3, 2026
Handshake status: UNKNOWNsecurity

Install and run

Setup complexity: low.

clawhub skill install s17bcar8wq0xhegs0ny6f57ypd8484bw:compound-eng-agent-native-architecture

Setup complexity is classified as HIGH. You must provision dedicated cloud infrastructure or an isolated VM. Do not run this directly on your local workstation.
Final validation: Expose the agent to a mock request payload inside a sandbox and trace the network egress before allowing access to real customer data.

Contract: missing

curl -s "https://www.xpersona.co/api/v1/agents/clawhub-iliaal-compound-eng-agent-native-architecture/snapshot"

Documentation

CLAWHUB

154,176 characters of source documentation, loaded on request.

Extracted files

5 files captured from the source.

SKILL.md

---
name: ia-agent-native-architecture
class: meta
description: >-
Design agent-native applications where agents replace UI users as the primary
actor. Use when designing MCP tools, agent-loop architectures, system prompt
design, hooks policy, shared-workspace file patterns, or self-modifying agent
systems.
---

# Agent-Native Architecture

## Working rules

- Keep authority, scope, approval, and runtime isolation in trusted orchestration; prompts alone cannot enforce them.
- Provide explicit completion and partial-progress signals, durable state, and observable action results.
- Validate capabilities with real tasks, including failure and interruption paths; do not infer improvement from elapsed usage.
- Use the selected topic's references and the architecture checklist to produce a concrete design with evidence and unresolved constraints.

## Core Principles

Five principles govern agent-native design. For detailed explanations, examples, and test criteria, see [core-principles.md](./references/core-principles.md).

| Principle | One-line test |
|-----------|--------------|
| **Parity** | Can the agent achieve every outcome the UI allows? |
| **Granularity** | Changing behavior means editing prose, not refactoring code |
| **Composability** | Can a feature be added by writing a new prompt, without new code? |
| **Emergent Capability** | Can the agent handle open-ended requests it wasn't designed for? |
| **Improvement Over Time** | Does the app work better after a month, even without code changes? |

## Focus Area Selection

1. **Design architecture** - Plan a new agent-native system from scratch
2. **Files & workspace** - Use files as the universal interface, shared workspace patterns
3. **Tool design** - Build primitive tools, dynamic capability discovery, CRUD completeness
4. **Domain tools** - Know when to add domain tools vs stay with primitives
5. **Execution patterns** - Completion signals, partial completion, context limits
6. **System prompts** - Define agent behavior in prompts, judgment criteria
7. **Context injection** - Inject runtime app state into agent prompts
8. **Action parity** - Ensure agents can do everything users can do
9. **Self-modification** - Enable agents to safely evolve themselves
10. **Product design** - Progressive disclosure, latent demand, approval patterns
11. **Mobile patterns** - iOS storage, background execution, checkpoint/resume
12. **Testing** - Test agent-native apps for capability and parity
13. **Refactoring** - Make existing code more agent-native
14. **Anti-patterns** - Common mistakes and how to avoid them
15. **Success criteria** - Verify your architecture is agent-native
16. **Hooks patterns** - Hook events, decision control, MCP matchers, async hooks
17. **CLI interface** - Design a CLI that agents invoke: output channels, exit codes, self-description, safety tiers
18. **Approval loop** - Durable human approval for agent-drafted external sends: content binding, single-winner claim, unkn

_meta.json

{
  "ownerId": "kn715jrbbh71q9zncr0bqdkr8n848q1a",
  "slug": "compound-eng-agent-native-architecture",
  "version": "5.0.1",
  "publishedAt": 1791046947157
}

references/action-parity-discipline.md

<overview>
A structured discipline for ensuring agents can do everything users can do. Every UI action should have an equivalent agent tool. This isn't a one-time check--it's an ongoing practice integrated into your development workflow.

**Core principle:** When adding a UI feature, add the corresponding tool in the same PR.
</overview>

<why_parity>
## Why Action Parity Matters

**The failure case:**
```
User: "Write something about Catherine the Great in my reading feed"
Agent: "What system are you referring to? I'm not sure what reading feed means."
```

The user could publish to their feed through the UI. But the agent had no `publish_to_feed` tool. The fix was simple--add the tool. But the insight is profound:

**Every action a user can take through the UI must have an equivalent tool the agent can call.**

Without this parity:
- Users ask agents to do things they can't do
- Agents ask clarifying questions about features they should understand
- The agent feels limited compared to direct app usage
- Users lose trust in the agent's capabilities
</why_parity>

<capability_mapping>
## The Capability Map

Maintain a structured map of UI actions to agent tools:

| UI Action | UI Location | Agent Tool | System Prompt Reference |
|-----------|-------------|------------|-------------------------|
| View library | Library tab | `read_library` | "View books and highlights" |
| Add book | Library → Add | `add_book` | "Add books to library" |
| Publish insight | Analysis view | `publish_to_feed` | "Create insights for Feed tab" |
| Start research | Book detail | `start_research` | "Research books via web search" |
| Edit profile | Settings | `write_file(profile.md)` | "Update reading profile" |
| Take screenshot | Camera | N/A (user action) | -- |
| Search web | Chat | `web_search` | "Search the internet" |

**Update this table whenever adding features.**

### Template for Your App

```markdown
# Capability Map - [Your App Name]

| UI Action | UI Location | Agent Tool | System Prompt | Status |
|-----------|-------------|------------|---------------|--------|
| | | | | ⚠️ Missing |
| | | | | ✅ Done |
| | | | | 🚫 N/A |
```

Status meanings:
- ✅ Done: Tool exists and is documented in system prompt
- ⚠️ Missing: UI action exists but no agent equivalent
- 🚫 N/A: User-only action (e.g., biometric auth, camera capture)
</capability_mapping>

<parity_workflow>
## The Action Parity Workflow

### When Adding a New Feature

Before merging any PR that adds UI functionality:

```
1. What action is this?
   → "User can publish an insight to their reading feed"

2. Does an agent tool exist for this?
   → Check tool definitions
   → If NO: Create the tool

3. Is it documented in the system prompt?
   → Check system prompt capabilities section
   → If NO: Add documentation

4. Is the context available?
   → Does agent know what "feed" means?
   → Does agent see available books?
   → If NO: Add to context injection

5. Update the capability map
   → Add row to tracki

references/agent-execution-patterns.md

<overview>
Agent execution patterns for building reliable agent loops: how agents signal completion, track partial progress for resume, select appropriate model tiers, and handle context limits.
</overview>

<completion_signals>
## Completion Signals

Agents need an explicit way to say "I'm done."

### Anti-Pattern: Heuristic Detection

Detecting completion through heuristics is fragile:

- Consecutive iterations without tool calls
- Checking for expected output files
- Tracking "no progress" states
- Time-based timeouts

These break in edge cases and create unpredictable behavior.

### Pattern: Explicit Completion Tool

Provide a `complete_task` tool that:
- Takes a summary of what was accomplished
- Returns both a terminal status and a signal that stops the loop
- Works identically across all agent types

Preserve `success`, `partial`, and `blocked` through tool results, checkpoints, and the final response. Stopping the loop does not establish successful completion. Before accepting `success`, run application-owned acceptance checks against the resulting state; an agent's summary or claimed verification is not that evidence.

```typescript
function registerCompletionTool(verifyTaskAcceptance: () => Promise<boolean>) {
  tool("complete_task", {
    summary: z.string().describe("Summary of outcomes and remaining work"),
    status: z.enum(["success", "partial", "blocked"]),
  }, async ({ summary, status }): Promise<ToolResult> => {
    if (status === "success" && !(await verifyTaskAcceptance())) {
      return {
        success: false,
        output: "Acceptance checks failed; report remaining work or continue.",
        shouldContinue: true,
      };
    }

    return {
      success: true,
      output: summary,
      shouldContinue: false,
      terminalStatus: status,
    };
  });
}
```

Supply `verifyTaskAcceptance` from the application, using observed artifacts or business state for the current request. Permit `partial` and `blocked` to stop with an explanation even when acceptance checks cannot pass.

### The ToolResult Pattern

Structure tool results to separate success from continuation:

```typescript
type TerminalStatus = "success" | "partial" | "blocked";

type ToolResult =
  | { success: boolean; output: string; shouldContinue: true }
  | {
      success: true;
      output: string;
      shouldContinue: false;
      terminalStatus: TerminalStatus;
    };
```

### Key Insight

**This is different from success/failure:**

- A tool can **succeed** AND signal **stop** (terminal outcome)
- A tool can **fail** AND signal **continue** (recoverable error, try something else)
- A completion tool can succeed at recording `partial` or `blocked` while the task remains unfinished

```typescript
// Examples:
read_file("/missing.txt")
// → { success: false, output: "File not found", shouldContinue: true }
// Agent can try a different file or ask for clarification

complete_task({ summary: "Organized all downloads into folders", status: "success"

references/agent-native-testing.md

<overview>
Testing agent-native apps requires different approaches than traditional unit testing. You're testing whether the agent achieves outcomes, not whether it calls specific functions. This guide provides concrete testing patterns for verifying your app is truly agent-native.
</overview>

<testing_philosophy>
## Testing Philosophy

### Test Outcomes, Not Procedures

**Traditional (procedure-focused):**
```typescript
// Testing that a specific function was called with specific args
expect(mockProcessFeedback).toHaveBeenCalledWith({
  message: "Great app!",
  category: "praise",
  priority: 2
});
```

**Agent-native (outcome-focused):**
```typescript
// Testing that the outcome was achieved
const result = await agent.process("Great app!");
const storedFeedback = await db.feedback.getLatest();

expect(storedFeedback.content).toContain("Great app");
expect(storedFeedback.importance).toBeGreaterThanOrEqual(1);
expect(storedFeedback.importance).toBeLessThanOrEqual(5);
// We don't care exactly how it categorized--just that it's reasonable
```

### Accept Variability

Agents may solve problems differently each time. Your tests should:
- Verify the end state, not the path
- Accept reasonable ranges, not exact values
- Check for presence of required elements, not exact format
</testing_philosophy>

<can_agent_do_it_test>
## The "Can Agent Do It?" Test

For each UI feature, write a test prompt and verify the agent can accomplish it.

### Template

```typescript
describe('Agent Capability Tests', () => {
  test('Agent can add a book to library', async () => {
    const result = await agent.chat("Add 'Moby Dick' by Herman Melville to my library");

    // Verify outcome
    const library = await libraryService.getBooks();
    const mobyDick = library.find(b => b.title.includes("Moby Dick"));

    expect(mobyDick).toBeDefined();
    expect(mobyDick.author).toContain("Melville");
  });

  test('Agent can publish to feed', async () => {
    // Setup: ensure a book exists
    await libraryService.addBook({ id: "book_123", title: "1984" });

    const result = await agent.chat("Write something about surveillance themes in my feed");

    // Verify outcome
    const feed = await feedService.getItems();
    const newItem = feed.find(item => item.bookId === "book_123");

    expect(newItem).toBeDefined();
    expect(newItem.content.toLowerCase()).toMatch(/surveillance|watching|control/);
  });

  test('Agent can search and save research', async () => {
    await libraryService.addBook({ id: "book_456", title: "Moby Dick" });

    const result = await agent.chat("Research whale symbolism in Moby Dick");

    // Verify files were created
    const files = await fileService.listFiles("Research/book_456/");
    expect(files.length).toBeGreaterThan(0);

    // Verify content is relevant
    const content = await fileService.readFile(files[0]);
    expect(content.toLowerCase()).toMatch(/whale|symbolism|melville/);
  });
});
```

### The "Write to Location" Test

Impl

Github ReposUpdated 8h agoRank 70

AionUi

Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!

MCPOPENCLAW

Github ReposUpdated 6mo agoRank 70

activepieces

AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents

OPENCLAW

Github ReposUpdated 6mo agoRank 70

cherry-studio

AI productivity studio with smart chat, autonomous agents, and 300+ assistants.