eve-agent-native-design

这段内容是审核时保存的快照。外部来源才是完整且最新的版本。

---
name: eve-agent-native-design
description: Design agent-native applications on Eve Horizon. Apply parity, granularity, composability, and emergent capability principles to make apps that agents can build, operate, and extend naturally.
triggers:
  - agent native
  - agent native design
  - design for agents
  - agent first
  - agentic app
  - agent native app
---

# Agent-Native Design for Eve Horizon

Build applications where agents are first-class citizens — not afterthoughts.

## When to Use

Load this skill when:
- Designing a new application or API on Eve
- Evaluating whether an existing app is agent-friendly
- Adding features that agents should be able to use
- Deciding between putting logic in code vs. in prompts
- Choosing how to handle inter-agent communication

## The Four Principles

### 1. Parity — Agents Can Do Everything Users Can

Every user action must have an agent-equivalent path.

**On Eve**: The CLI IS the parity layer. If a user can do it through `eve ...`, an agent can too. When building your app, apply the same principle:

| Check | How |
|-------|-----|
| Can agents create/read/update/delete every entity? | Map UI actions to CLI/API equivalents |
| Are there UI-only workflows? | Expose them as API endpoints or CLI commands |
| Can agents discover what's available? | Provide `list` operations for every entity type |

**CRUD Completeness**: For every entity in your app, verify agents have Create, Read, Update, and Delete paths. Missing any one breaks parity.

### 2. Granularity — Atomic Primitives, Not Bundled Logic

Features emerge from agent loops, not monolithic tools.

**Wrong**: `deploy_and_monitor(app)` — bundles judgment into code
**Wrong**: `classify_and_organize_files(files)` — agent should decide classification
**Right**: `eve build create`, `eve build run`, `eve env deploy`, `eve job follow` — agent decides the sequence

**On Eve**: The manifest defines WHAT (services, pipelines), the agent decides HOW and WHEN to compose them.

**Design test**: To change behavior, do you edit prose (prompts/skills) or refactor code? If code — your tools aren't atomic enough.

### 3. Composability — New Features = New Prompts

When tools are atomic and parity exists, you add capabilities by writing prompts, not code.

**Eve example**: The `eve-pipelines-workflows` skill adds pipeline composition capability. No new CLI commands needed — the skill teaches agents to compose existing `eve pipeline` and `eve workflow` commands.

**Your app**: If adding a feature requires new API endpoints, you may be bundling logic. Consider whether existing primitives can be composed differently.

### 4. Emergent Capability — Agents Surprise You

Build atomic tools. Agents compose unexpected solutions. You observe patterns. Optimize common patterns. Repeat.

**Eve example**: Agents compose `eve job create --parent` + `eve job dep add` + depth propagation to build arbitrary work hierarchies. The platform didn't prescribe this — agents discovered it from atomic primitives.

## Platform Capabilities for Agentic Apps

Beyond the four principles, Eve provides (or is building) specific primitives that make agentic apps dramatically simpler:

### Job Attachments — Structured Context Passing

Pass plans, reports, and insights between agents without file gymnastics. Attach text documents (markdown, JSON, YAML) to jobs. Downstream agents read attachments from parent jobs. This solves 80% of the "agents passing structured context" problem.

### Service Account Auth — Backend-to-API Communication

Use `eve auth mint` (today) or service accounts (emerging) to authenticate app backends. Every app with a backend needs a non-user token for API calls. Scoped permissions enforce least privilege.

### Org Document Store — Persistent Agent Knowledge

Agents accumulate knowledge that outlives individual jobs: architecture reports, risk assessments, conventions. DB-backed with full-text search and agent-native search/replace editing via PATCH operat