Product
The chat box is the least interesting way to start an agent
Most real work does not begin with someone typing a question. It begins at 6am, or when a payment fails, or when another system calls yours. Agents should start the same way.
Nearly every agent demo starts the same way: a person types into a box and something impressive comes back. It is a good demo. It is also a strange picture of work, because very little of what a business does all day begins with somebody remembering to ask.
Invoices get chased because it is the first of the month. A refund gets reviewed because a payment failed. A lead gets researched because a form was submitted at 2am. The work has a cause, and the cause is almost never a chat message.
Three ways work actually arrives
- On a schedule. The weekly report, the nightly reconciliation, the sweep that checks whether anything has gone stale. Nobody should have to be awake for these.
- From your own code. Your product calls the agent through the API the way it would call any other service, and gets a result back.
- From an event somewhere else. A message lands in Gmail, a pull request opens on GitHub, an order is placed on Shopify, a charge fails on Stripe, someone writes in on Telegram or WhatsApp.
In Yekar.AI these are all triggers on the same agent. The agent that answers a person in a conversation is the same one that wakes on a schedule or reacts to an event - same instructions, same tools, same limits. What changes is who or what started the run.
A trigger changes the questions
When a person starts a run, a lot is implicit. They are there to read the answer, they will notice if it is nonsense, and their identity is obvious. Take the person away and each of those needs an explicit answer.
Who is the agent acting as, when nobody asked? Where does the output go, when nobody is waiting for it? And what happens to the step that needs a human decision, at an hour when no human is around? This is where approvals earn their place: a run that started from an event can pause at the gated step, wait for a named person for as long as it takes, and carry on from where it stopped.
If an agent only runs when someone remembers to ask, the remembering is still the job.
Events are noisy
The downside of event triggers is volume. Systems emit far more events than there is work. A shared inbox receives newsletters; a repository gets a comment that says "thanks". An agent wired to every event will spend most of its budget deciding there is nothing to do.
So the useful question is rarely "can it react to this?" It is "which of these should start a run at all?" Connect the narrow event, not the broad one - the failed charge, not every charge - and the agent's record stays a list of work done instead of a list of things it looked at and ignored.
The chat box is still there, and it is still the fastest way to find out whether an agent is any good. It just should not be the only door.