> ## Documentation Index
> Fetch the complete documentation index at: https://docs.joystream.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Agent Engineering

> Generating an agent is getting easy. Trusting one is not. Agent Engineering is the discipline that closes the gap.

Agent generation is becoming abundant. Trustworthy execution is not.

Within a year, anyone will be able to describe an agent and generate something that looks plausible. The scarce capability is not making one. It is engineering agents that can be trusted with real organizational work.

## Generation and engineering

```mermaid theme={null}
flowchart LR
    subgraph G["Agent generation"]
        direction TB
        G1[Prompt] --> G2[Agent] --> G3[Production]
    end
    subgraph E["Agent Engineering"]
        direction TB
        E1[Intent] --> E2[Capability spec] --> E3[Agent build] --> E4[Runtime recipe]
        E4 --> E5[Conformance] --> E6[Safe run] --> E7[Evidence]
        E7 --> E8[Human review] --> E9[Controlled promotion] --> E10[Production]
        E10 --> E11[Observation] --> E12[Improvement]
    end
```

Generation without rigor floods a company with agents that are fast to make, hard to predict, and nobody's job to maintain. Gartner expects more than 40% of agentic projects to be cancelled by 2027 — for lack of trust, not lack of capability.

## What the discipline extends

Agent Engineering extends the practices that made software dependable to the creation and operation of AI agents: specification, versioning, compilation, conformance, testing, controlled access, review, promotion, observability, evidence, collaboration, ownership, and continuous improvement.

Software engineering asks one question:

> Does the software behave according to its specification?

Agent Engineering must ask a second:

> Did the agent deliver the intended organizational outcome, within its approved boundaries?

The category promise follows from that.

<Note>
  Agents should earn their way into production.
</Note>

## Why this needs a product

The people who own a capability — sales, marketing, operations, finance — should own the agents that do it. The capability is theirs.

But making an agent you can trust in production still takes an engineer: someone to audit the logic, wire up a sandbox, write evaluation loops, and watch what it touches. So when a leader tells their team to build agents, every capability owner effectively needs a software engineer standing beside them.

If every capability owner needs a software engineer, nothing has been democratized. That leaves organizations with a false choice: build nothing, or ship a chat toy into production and hope it doesn't break something downstream.

JoyStream closes that gap. You describe what you want, and JoyStream turns intent into something you can inspect, verify, and safely evolve: a readable specification, a reviewable plan of the work it will do, and a safe run before it touches anything real. By the time you say "I want to deploy this", you have the evidence to justify the decision.

Deployment stops being a leap of faith. It becomes a review of evidence.

## Bounded and intelligent

The distinction that makes this work is in the runtime recipe.

|                     | Bounded                                                          | Intelligent |
| ------------------- | ---------------------------------------------------------------- | ----------- |
| **Workflow**        | Yes — but brittle. Rigid steps that shatter when reality shifts. | No          |
| **Vibe agent**      | No — improvises outside the guardrails you intended.             | Yes         |
| **JoyStream agent** | Yes                                                              | Yes         |

The capability is engineered as a plan, while the agent reasons through the messy middle that scripts can't handle — "step X failed because of Y, so skip Z" — always staying within the intent and boundaries that were approved.

Think of it as a route plan. You approve the journey before the car leaves the driveway. The driver still chooses the best road to each destination.

## The verification difference

Agent Engineering doesn't stop when the agent runs. It verifies that the capability was actually delivered — not that the email API returned 200, but that the new employee was successfully onboarded.

Every execution becomes part of the capability's history: evidence, observations, and outcomes recorded in business language rather than walls of tool calls. The capability becomes easier to understand, easier to trust, and easier for the next person to improve.

## Next

<Columns cols={2}>
  <Card title="The lifecycle" href="/concepts/lifecycle" icon="git-branch">
    Plan, Build, Conform, Dry Run, Pilot, Live — and the two loops.
  </Card>

  <Card title="Evidence" href="/concepts/evidence-and-memory" icon="shield-check">
    What counts as proof that a capability worked.
  </Card>
</Columns>