Product
Describe the agent, then read what you got
Describing an agent in a sentence is the easy part. What matters is being able to read, question and change what that sentence turned into.
"Describe an agent. Ship it anywhere." is the line at the top of our site, and the first half of it deserves some scrutiny. Plenty of products let you type a sentence and get an agent. Fewer let you see what the sentence became.
That second part is the one we care about, because a description is not a specification. "An agent that follows up on overdue invoices" leaves almost everything open: which invoices, in whose name, how many times, in what tone, and what happens when the customer replies that they paid last week.
A blank page is the wrong starting point
Asked to configure an agent from scratch, most people stall at the first empty field. Not because the fields are hard, but because nobody thinks about their work as a list of settings. They think about it as a job: when this happens, do that, unless.
So the Agent Builder starts from the job. You say what the agent is for, in the words you would use to brief a new hire. The builder - itself an agent - turns that into a setup: the instructions, the triggers that should start it, and the knowledge it found that looks relevant.
The output is something you can read
What comes back is not a sealed box with a name on it. It is the same configuration you would have written by hand, laid out the same way, and every part of it is open to change.
This is the difference that matters. A generated agent you cannot inspect asks for trust at exactly the moment you have no basis for it. A generated agent you can read is a first draft - and reviewing a first draft is something everyone already knows how to do.
A sentence can start an agent. It should never be the only place the agent is defined.
What to check in the draft
- The assumptions. Wherever your description was vague, the draft made a choice. Find those choices and decide whether you agree with them.
- The triggers. Is it starting when you expected, and only then?
- The knowledge. Is it drawing on the documents you would have picked, and are they current?
- The edges. What does it do when the answer is not in its knowledge, or the request is outside its job? If the draft does not say, add it.
Nothing special about a built agent
What the builder creates is ordinary configuration. There is no separate kind of agent that only the builder can make, and nothing it sets up is hidden from the person who asked. Two months later, when someone else on the team opens that agent, they cannot tell whether it was described or written by hand. They should not need to.
Describing is how you start. Reading is how you know what you have. The second half of the line - ship it anywhere - only makes sense once both are true.