Give Your AI Hire a Job to Finish

You hired someone to get the event page ready. You explained what it needs to do. But every time they finish one step, they stop and wait for you to tell them the next one.

You’re still managing every move.

Treat your AI Hire like someone you hired to do a job. Explain the result you need, how you’ll judge it and which decisions need your approval. Let it work through the steps and bring back the result, or a problem that genuinely needs you.

Your cYpher.camp AI Hire is powered by Hermes Agent. The /goal command helps it keep working toward that result without waiting for another prompt after each round. It is still AI: it can miss things, and its work needs checks. You are delegating within agreed limits, not handing over every decision.

Say you’re an event promoter with a local show to launch. The flyer is ready, but the checklist and RSVP page still need work. You give your Hire the job of building a prototype, a test version you can try before guests use it. This event is fictional, not a customer result or a live signup service.

The first draft still owes you work

Say your brief is for Neighborhood Sessions: a local R&B night with room for 40 people. Supply the event details, launch tasks and made-up guest records. Give each guest a permanent ID to tell a repeat signup from a new person.

The first draft has the event details and tasks you can edit. But it confirms a guest after the room is full, then counts that guest twice. The page looks good and still gets the important part wrong.

With /goal, your Hire keeps the job in view across rounds of work. After each round, a second AI checks the last response against your goal. That checker is called the judge.

If the job is still unfinished, the checker can send your Hire back to work in the same chat. It keeps going within the agreed limits, pauses when blocked or out of turns, or waits when you pause it.[1]

Your Hire needs to fix the waitlist, count each guest once, then check again. You should not have to type “keep going” to get a requirement you already gave it. The handoff is the page, test results and questions that need your call.

Decide what would convince you

“Make an event app” leaves your Hire guessing. You decide what a finished page must do. Include how to check it, what it can change and when to ask you. That written agreement is the completion contract. I would start with this brief.

Before trying this, have the person setting up your Hire confirm that /goal is available and the test limits are enforced. Review the brief first: /goal starts work right away. The setup notes below cover those controls; this assignment alone does not install them.

Outcome: build a local Neighborhood Sessions test page from the made-up event details and guest records only. Show event details, launch tasks I can edit, confirmed guests and a waitlist. Label every screen as a prototype. No real guest information.

Verification: fill the room, then add one more guest and show them on the waitlist. Add the same event-and-guest ID twice and prove it counts once. Edit a launch task, reload the page, and show the edit is still there. Try the controls with a keyboard and on an upright phone screen. Return the test page and results for each check. Say what you did not test.

Boundaries: change files only in the separate test folder. No public signup, messages, bookings, payments, pricing changes or publishing. Stop if event details are missing, capacity figures conflict, you need access outside that folder, or you reach a limit. Bring me the question instead of making up a venue rule.

Why I use goals for builds

I used Hermes /goal for the initial build of the live cYpher.city Arcade on cYpher.camp. I would put it at roughly 80% of the way there. That is my estimate, not a count of the code. I still had to review the work, connect the pieces and improve it.

That is why I care about getting past the first good-looking screen. The Arcade has four learning districts: AI Heights, Market Street, Firewall Quarter and Chain Docks, leading to Agent Tower. Its reward campaign is currently unavailable; badges and XP are not AI credits. The link shows the game after later work, not independent proof of what happened in my first run.[2]

The Arcade brief, reconstructed

This is a reconstructed brief, not my original prompt or a record of bugs from that run: make each district reachable, keep each tower’s learning requirements, make battles work by touch on an upright phone, and keep saved progress working after reload. Return the local game and check results. Do not publish, connect accounts or promise rewards.

Your event page needs different checks: capacity, repeat signups and saved tasks. But the way you assign the job is the same. Define what done means, let your Hire work through the steps, then review what comes back.

Watch the work continue

The event-launch script below shows your Hire carrying that job through a failed check and a repair without asking for the next step. The other tabs show when to stop for a missing venue rule or a decision about sponsor records. All three are fictional scripts, not live runs.

You accept the work, then delegate the routine

The judge can stop too early or keep going after the useful work is done. You accept the work. Try the page and inspect the test results first; a confident summary cannot tell you whether the waitlist works.[3]

But I would not have you approve the same capacity check forever. Once the checks and controls work, give permission for that routine in advance. After an edit, your Hire can rerun the checks and fix failures within the same limits.

Keep a record and review samples now and then. Test that problems reach you and that you can pause the loop. Pausing stops further rounds; it does not cancel an action already underway.

Changing capacity, making up a venue rule, merging sponsor records or opening public signup still needs your separate decision. Passing the tests grants none of that permission.

Judge the trial by how much of the job is off your plate, including your review time and AI spending. If you still direct every repair, narrow the assignment or improve the checks. Give your Hire a job to finish, with room to do it and clear reasons to come back to you. The event still needs your judgment. Repeating instructions should take less of your day.

Setup notes for the person configuring your Hire

These notes are for the person configuring the test environment. Keep the job brief above as your assignment. Verify command support, tool access and spending controls before starting; being powered by the same software does not prove every option is enabled on every Hire.

The person setting up your Hire must limit which files it can change and which tools it can use. They must remove access keys for live services and turn off outside actions, such as sending messages.

For this test, use a four-turn goal budget and a $2 total cap for both your Hire and the judge. The billing or execution system must enforce that cap. These are example limits, not a price quote. If the cap cannot be enforced, do not start the paid loop.

A turn budget is not a dollar limit. And writing “do not publish” does not remove a publishing tool. The setup must enforce those limits outside the prompt.

The goal feature supports registered quality gates: code checks that must pass before it marks the goal done. Asking for a capacity test does not register one; the person doing setup must add it. A passing check only proves what it tested.[4]

The service running your Hire must remain alive while it works. A saved goal lets you pick up where you left off; it does not mean work continued while that service was stopped. If you run it on your own computer, putting that computer to sleep stops the work too.