How to define what your AI agent must do

Before you write a single prompt, you write the job. The reason most AI agents fail is not the model and not the tools, it is that nobody ever wrote down what the agent was actually responsible for. So it sort of does everything and reliably finishes nothing. The fix is the part almost everyone skips: define the agent's requirements first, in one sentence, the way an engineer defines a system before building it.

Why most AI agents fail before they are built

Two things go wrong every time. The do-everything agent: handed five jobs at once, it does each one halfway, quotes a price it should never quote, answers an Arabic enquiry in clumsy English, and you find out from an angry customer, not from a test. The vibe-briefed agent: told to "be helpful and professional," it gives a different answer to the same question on Monday and Tuesday, and no one can say which was right. Both demo beautifully. Both break in production, because the agent was never given one thing to own.

A job is one outcome, owned end to end

A task is "reply to a message." A job is the whole loop that produces an outcome: the agent senses what came in, decides what to do, acts, and checks its own work, then repeats. Owned end to end means there is no gap where a human quietly babysits it, either it finishes the outcome or it hands off on purpose, never by accident. The test of a real job: if you cannot say it in one sentence, you have two agents wearing one coat.

Write the AI agent's requirements in four parts

A job statement has the same four parts every time. The outcome, what done looks like (booked or qualified, not "helps with bookings"). The trigger, what starts it (a new WhatsApp or Instagram message, in Arabic or English). The boundary, where it stops and hands to a human (anything clinical, anything it is unsure of). The bar, set by the cost it kills (a lead that waits ten minutes rarely converts, so speed becomes part of the job). Miss one of the four and that is the gap the agent falls through later.

The same discipline used to fly a satellite

In flight software this document has a name: the User Requirements Definition. It is the first thing written, before any design or code, because you cannot touch a satellite after launch, so nothing is real until it is defined and signed off. An AI agent earns trust the same way. We keep the agent's job to one page and call it the Job Card, but it is the same rigor, and it is what separates a flight-grade build from a chatbot that breaks in a month.

A worked example: a clinic's lead-response agent

Take a Business Bay aesthetic clinic. Enquiries land on WhatsApp and Instagram, in Arabic and English, day and night. Built one part at a time, the job becomes a single sentence the owner can read and sign:

"Answer every new enquiry within two minutes, in its language, and book it or qualify it, 24/7, handing anything clinical or custom-priced to a human."

Those four parts, in full:

That one sentence is the agent's requirement. Now every prompt, every tool, and every test has one thing to answer to, and everything you build next traces back to it. Change the card and you change them all.

The Job Card: the gate before you build

A good job is signed off before the first prompt is written. It states one owned outcome, names the trigger, draws the boundary, quantifies the cost it kills, and is written in the owner's words, clear enough that the owner, not just the builder, can confirm it. Get this wrong and the most elegant build solves the wrong problem.Once your agent's job fits on one card, the next step is to draw the system that delivers it: the blocks, the data flow, and the modes.