Skills, not flows
We replaced the flowchart builder with a document. Here is what an owner writes, what the agent reads, and how a skill goes live in one press.
The first version of Chirpedly had a flow builder. Triggers, conditions, branches, actions, drawn on a canvas. It was capable, and almost nobody could finish one. A refund flow with the branches a real refund needs ran to twenty nodes, and the owner who drew it could not tell, a week later, what it would do with a customer who had already been refunded once.
The replacement is a document.
What an owner writes
A skill has five fields, in the order the work happens:
- Name. What the owner would call it. "Refund an order."
- Use when. One sentence about the job. This is the only part the agent reads when it decides which skills a message needs, so it is written for meaning, not keywords.
- Flow. The steps, starting with whatever the agent must ask for.
- Rules. The business rules, the limits, and the situations that go to a person.
- Reply. What the reply must cover. Not the reply itself: a scripted message cannot know what the tool returned.
Chirpedly formats it. The owner never meets a file name, a header, a list marker or an identifier. Type the name and the identifier is formed; number nothing and the steps are numbered. The full text is one click away for anyone who wants it, and it is the same bytes, not a rendering.
What the agent reads
When a customer writes in, the agent sees only the names and one-line descriptions of the skills installed on it. It picks the ones the message is about, by meaning, so "return what I paid" reaches the refund skill without sharing a word with it. Only then does it open the full text of the skills it chose, and only the tools those skills name are handed to it. A skill that does not mention refunds cannot issue one, whatever the customer types.
One press takes the skill live
Publish writes down whatever autosave is still holding, validates the skill, publishes it and installs it on its agent. If the validator refuses the skill, its words stay on the page and nothing new reaches a customer. A live skill cannot be published again until its text changes.
Pause takes a live skill out of service without deleting it. Resume puts the unchanged text back; an edit is published from the skill's own page. The state beside its name says Draft, Live, Paused or Archived, so there is no separate agent-level publishing step to remember.
What a flow had that a skill does not
Timers, notifications to the owner, starting from a provider event. Some of those come back as tools with their own proof; some are gone on purpose. Every configuration written under the old model was converted, deterministically and with its original kept beside it, into a draft the owner can read and publish, or not. Nothing was rewritten by a model, because a paraphrase of a rule is a different rule.