Build agents by conversation, not config

There are two ways to tell software what an agent should do. You can write the configuration by hand — wiring tools, triggers, and control flow in a schema someone designed — or you can describe the agent in plain language and let the platform draft that configuration for you. The second is faster, and it changes who gets to build.

The hidden cost of config-first

Config-first tooling has a tax that doesn't show up in the demo. Someone has to learn the schema. They have to know that a "tool" connects to a "channel" through a "trigger," that retries live under one key and timeouts under another, and that a typo three levels deep fails silently at run time.

That knowledge becomes a bottleneck. The person with the idea for the agent — the operations lead who knows exactly how invoices should be triaged — isn't the person who can express it in YAML. So the idea waits in a queue behind whoever owns the config.

Conversation collapses the queue

A conversational builder lets the person with the idea state it directly:

"When an invoice email arrives, pull the line items, match each one against an open purchase order, and post the matches to our ERP. If the total is over $25,000, pause and ask a human to approve before posting."

From that, the builder drafts a working configuration: an email trigger, an extraction step, a matching sub-agent, a conditional human-in-the-loop approval, and the ERP tool call. The operations lead reviews it in plain terms — yes, that's the threshold; no, match on PO number not vendor name — and refines by talking, not by editing braces.

Conversation doesn't mean magic

A fair objection: "I don't want a black box deciding how my agent works." Neither do we. Conversation is the input method, not a replacement for the artifact.

The output is still a concrete, inspectable configuration. You can:

• See the whole agent on the visual canvas as a graph of orchestrator, sub-agents, tools, and channels.
• Rewire connections directly when the draft isn't quite right.
• Diff and review changes the way you'd review any other configuration change.

The builder gets you to a correct first draft in minutes instead of hours. It doesn't hide what it built.

Where this matters most

The conversational approach pays off most when the people who understand the work aren't the people who understand the schema. That's nearly every enterprise:

• A support manager describes an escalation agent without learning a workflow DSL.
• A finance analyst sets a reconciliation threshold without filing a ticket.
• An engineer reviews and hardens the generated config instead of authoring it from scratch.

Config-first tools optimize for the person who already knows the system. Conversation-first tools optimize for the person who knows the problem — and then hand the engineer a reviewable artifact to harden.

That's the trade we'd make every time.