---
name: launch
version: 3
supersedes: launch@2
title: Introducing .intent
lock: sha256:85d01b6ce5489f22543cf20d1b5a339086676b2dcd33b9cc2823710cecfacefd
---

# Goal
Introduce .intent plainly, so a reader understands the four parts and the locking rule, and feels free to shape the rest.

# Evals
- test: under 600 words, with one example file containing name, goal, evals and fulfillment → [ "$(intent words "$INTENT_FILE")" -le 600 ] && intent examples "$INTENT_FILE"

# Fulfillment

A file format for what you actually want.

Agents are getting good at doing the work. What hasn't gotten easier is saying what the work is for. That's what `.intent` is for.

A `.intent` file has four parts:

- **Name**: what this is.
- **Goal**: one sentence about the outcome you want.
- **Evals**: the results that prove the goal is reached.
- **Fulfillment**: the steps an agent follows to get there.

An agent reads the fulfillment and runs it. The evals tell it, and you, whether it worked.

The rule that makes it interesting: goal and evals are locked. The fulfillment is free. An agent can rewrite the steps as often as it likes, try another approach, swap tools, or start over, as long as the evals still pass. If you want a different outcome, that's not an edit. That's a new version.

Here's a tiny one:

```intent
---
name: booking-reminder
version: 1
---
# Goal
Players get a reminder two hours before every confirmed booking.

# Evals
- test: a booking at 18:00 triggers exactly one reminder at 16:00
- judge: the reminder makes sense in a single line

# Fulfillment
Listen for confirmed bookings. Schedule a push notification two hours before start time.
```

Why split it this way? Because it answers a question I keep asking myself: when agents do the work, what is my input still for?

My answer so far is two things: deciding which problem is worth solving, and saying precisely what done means. That's the locked part, and it's human. The how belongs to the agent.

Writing evals first sounds hard, but for me it turned out to be most of the job. When I sit with a real problem, I can write most of what "done" looks like before anything gets built. Building just sharpens a few edges.

And when an agent passes every eval and I still don't like the result, that isn't the agent's failure. My evals missed something. I fix them and bump the version. Over time the version history becomes a record of what I learned "done" really means.

## What I'm leaving open

I've kept the core small on purpose. Everything else is an open question, and these are the ones I most want other people to answer:

- **How should evals be written?** Scripts with a hard pass or fail, rubrics an AI judges, a person reading the result? Which kind of "done" belongs to which?
- **How should the lock work?** A hash is one way. What would make you trust that nobody quietly moved the goalposts?
- **What runs the file?** A coding agent, a CI job, a scheduler, something that doesn't exist yet?
- **How strict should versioning be?** Is every changed eval a new version, or only a changed goal?

The right answers depend on your work and your taste. I'd rather keep the core small enough to adopt in an afternoon and let the people using it shape the rest.

If you try it, tell me how you answered these. That's how the rest of .intent gets written.