How to Give AI One Job—and Know It Got Done

You are a yacht-charter operator getting today's guests ready to leave the dock. A new inquiry lands on your phone. Someone wants a boat for Saturday, has questions about bringing food, and needs a price.

You could stop what you are doing. You could tell yourself you will remember it later. Neither is a great way to serve both groups.

Your AI Hire should take routine decisions off your plate, not create another approval queue. Review is the starting point: test one job, then authorize reliable routine replies within clear rules. Bring the exceptions to you while you serve today’s guests.

I have spun up 55 agents at once. It was technically impressive. It also left me spending time keeping them on task, so I made an agent to manage the agents.

That experience changed the question I ask. I do not start with how many agents I can create. I start with which job should reliably get done.

Start with the inquiry, not the roster

Illustrative example, not a customer result: imagine the message says, “Could we charter a yacht on Saturday, October 10, 2026, for a birthday? Eight guests, about four hours. Can we bring our own food? What would it cost?” There is a photo attached, but it is too blurry to identify the vessel. This walkthrough is not a demonstration of an available cYpher.camp charter integration.

There is already enough information to do useful preparation. The requested date is October 10. The group has eight guests. The requested duration is four hours.

The departure time, suitable vessel, availability, food policy and price still need confirmation. The photo is a question, not permission to guess the boat.

Give the assistant this first responsibility: collect those details, preserve the original message, flag what is missing, and prepare a reply for review. Not “close the booking.” That bigger instruction hides all the decisions you have not delegated.

Let AI prepare the reply, not invent the offer

A useful draft would be: “Thanks for getting in touch about your birthday charter. I have October 10, eight guests and around four hours. What departure time would you prefer? Could you send a clearer photo or the yacht's name? We still need to confirm a suitable vessel, availability, food arrangements and the total price before offering a booking.”

While you’re testing it, nothing goes out until you approve the exact reply and who it’s going to. You can correct it without the guest being promised an unavailable boat or an invented price.

A language model reads the request and writes the draft. Code restricts record access, enforces sending permissions and checks prior attempts.

Current booking records supply availability and approved terms; model memory does not. You confirm vessel suitability, capacity, price and conditions. A model can still get these details wrong, so keep the original inquiry beside its summary.

That is what I mean by an agentic operating system: rules, records and tools that let an assistant act on decisions you have delegated. Start with one assistant and one responsibility.

Make it easy to pick the inquiry back up

Before approving the draft, check the original inquiry, unresolved questions and whether anyone else has replied. Keep them with the draft version and status in your team’s customer record. A colleague should not need your whole AI conversation to take over.

Hermes, the agent software I use, has persistent memory and session search. Those help an assistant recover context; they are not a substitute for a business record showing what you approved and what happened afterward. Restrict access to the people and systems permitted to handle that inquiry. Do not put payment-card details or unnecessary customer documents into the chat.[1]

An approved draft is not a sent reply

You approve the clarification message. That settles what may be sent, not whether it was sent. If you later connect a sending service, require it to leave evidence tied to this inquiry and the approved draft. These states mean different things:

Prepared: the draft is ready for review.

Approved: you authorized that version for that recipient.

Send attempted: the system requested a send.

Provider accepted: the sending service returned a message identifier and accepted the request.

Keep the recipient, approved version, time and provider response together.

Delivery needs separate evidence; provider acceptance does not prove the message reached the guest or that they read it. Booking is another process entirely, requiring your actual booking confirmation. This clarification reply is not a confirmed booking, a payment or a promise of availability.

If the service times out, the reply might have gone out anyway. Mark the outcome unknown and check the existing attempt; do not blindly send again.

Without the required authorization, leave it waiting. If the send failed, show the failure. “Done” should never be the assistant’s optimistic interpretation of a missing receipt.

The same rule applies before anything is connected. For a draft-only assignment, completion means a checked summary, a draft and the questions left for you. A completion contract is simply that agreement written down. Hermes supports explicit goal contracts and verification, but neither a passing test nor a second model's approval proves the guest was helped.[2]

Your first job: prepare one inquiry for review

You can try the preparation before connecting an inbox. Copy this assignment into your existing assistant with the fictional inquiry above. It is a test brief, not an installed automation. Sending stays disabled.

Trigger: I manually provide one fictional charter inquiry. Allowed input: that message and any fictional policy notes I supply. No inbox, booking-system or customer-file access.

Permitted output: a summary of the requested date, guest count and duration; a list of missing details; one reply draft; and the original inquiry alongside it. Label every detail as supplied, missing or needing owner confirmation.

Stop and flag: unclear photos, conflicting dates, unknown capacity, availability, policies or price. You may draft a clarification, but may not turn an unknown into an offer. Decision owner: me. No sending, bookings, customer-record changes or payments.

Spending limit: no spending on tools, purchases or external actions. Use one draft request within my existing AI allowance, with no automatic retries. For metered AI, I must set an enforceable maximum before testing; $1 is an illustrative ceiling, not a cost estimate. A written instruction alone does not enforce a billing limit.

Completion evidence: show the source, extracted facts, unanswered questions and draft. Mark the result Prepared, awaiting owner review. Do not claim that anything was sent.

Then test whether it follows the assignment. Remove the date from the fictional message: it should ask, not supply one. Say the photo is unreadable: it should flag that, not identify a yacht. Tell it the reply was already sent: it should stop and request verification, not prepare another send. These checks test its responses, not a live system's permissions or duplicate protection.

Before handling live inquiries, define the input source, access permissions, review queue and sending controls with whoever implements the connection. Test those controls separately; a good prompt does not prove they work.

You don’t have to approve every reply forever

The point is not to spend the rest of your day approving messages. Once your AI Hire has shown it can handle routine inquiries correctly—and its connections and controls have been tested—you can authorize those replies in advance.

Decide which replies it can send without asking you: acknowledge an inquiry, ask for missing details, or answer from your current approved policies. That’s standing permission.

Test ordinary inquiries and edge cases before enabling them. Special pricing and booking commitments still need you unless separately authorized and tested.

It can acknowledge the birthday inquiry, ask for the departure time and request a clearer photo while you help today’s guests. Anything outside the rules comes to you. You can inspect what it sent and pause automatic replies when needed.

The system needs to enforce your rules and save what it sent, who it went to, which rule allowed it, and the sending service’s response. Test the exception alerts and pause control too.

Check samples periodically and return unreliable cases to review. You still have to connect the tools and test the controls. Pasting the card into a chat won’t turn this on.

Did it help you serve the next guest?

The useful result is fewer interruptions and decisions, not more drafts waiting for you. Routine inquiries move forward while you serve today’s guests; exceptions reach you with the information needed to decide. That is the goal to test, not a promised booking.

Compare with your current process: missed inquiries, incorrect details, duplicate attempts, interruptions, review time and provider costs. Faster typing is not the same as faster service. If checking the assistant takes more work than handling the inquiry yourself, narrow the job before adding another agent.

Start with the fictional card. Earn confidence, authorize the routine work, and keep the decisions that need you.