Lysterium

Field notes / AI operations

Give your AI a job description before you give it the keys

Lysterium · Published

An AI assistant can write a convincing follow-up email and still offer the wrong service, use an expired price or contact someone who already booked. Better prose will not fix any of those mistakes.

Before connecting another app, write down the job. What should the assistant read? What should it produce? What must it leave alone? And what evidence would convince you that it finished?

That is a useful way to think about AI skills: written operating instructions for a specific piece of work. Start there, then decide how much automation the task deserves.

A skill gives the task somewhere to live

The Agent Skills format packages instructions in a folder with a SKILL.md file. That folder can also include scripts, references and templates. Compatible agents load those instructions when the task calls for them.

For a business owner, the useful part is having one procedure to correct. If an assistant keeps using the wrong tone, update the writing instructions. If it confuses an appointment request with a confirmed booking, add that distinction to the procedure and test it.

A folder of instructions is not an access-control system. Writing “do not send” in a file does not remove an email tool's ability to send. For a draft-only task, use an account or integration that cannot send, or require a separate approval step that the assistant cannot bypass.

Try it on an ad brief, not your ad account

Consider a hypothetical shop that wants fresh ads for a product. “Make some ads for this” leaves the assistant to decide which details matter. A better job is to prepare a review pack from an approved product page and a current offer sheet.

The pack should contain a few different angles, the product facts each angle uses, and anything the assistant could not verify. Suppose the page says “water-resistant” but a review calls the product “waterproof.” The review is not permission to strengthen the claim. Keep the approved wording and flag the disagreement.

Give the task a clear finish: save the proposed copy and its sources in one review file. No campaign creation. No budget change. No invented discount. You can judge the work without wondering what else happened in the account.

For this example, a rejected draft can be more useful than a polished one. If the price sheet is missing, the correct output is a request for the price, not a plausible number. If every angle relies on an unsupported benefit, you have found a product-evidence problem before paying to advertise it.

Use the same approach for appointment enquiries

Now take a hypothetical service business. An enquiry arrives asking about availability. The assistant has a service list and can read the enquiry, but it cannot see the booking calendar.

It can draft a reply that asks for the missing details or points to a booking page. It cannot truthfully confirm Tuesday afternoon. The procedure should say so, and the test should include a customer who asks for a specific time.

Separate the stages in your records: enquiry received, reply drafted, appointment requested, appointment confirmed. Otherwise, a report can count interest as booked work. Someone needs to own the confirmation step, whether it is a person or a tested calendar integration.

This is also where repeated runs matter. If the same enquiry arrives twice, should the system create two tasks? Usually not. Keep a stable enquiry identifier and check whether it was already handled. A written instruction helps explain that rule; the software needs to enforce it.

Keep business facts separate from the procedure

Your service area, product specifications and refund policy should not be copied into twenty prompts. Keep an approved reference with an owner and a review date. Have the skill point to it.

A small linked wiki can do that job. One page describes the offer. Another records the fulfilment limits. A third explains which evidence is needed before making a claim. The connections help a person or an assistant find the relevant material.

Do not treat the wiki as automatically correct because it is tidy. Old information needs to be marked as old. Conflicting instructions need a decision. Private customer records should stay in the appropriate system rather than becoming convenient examples in a general knowledge folder.

Test the awkward cases before adding a schedule

Run the procedure manually with a normal input first. Then give it an incomplete one, a duplicate and a contradiction. Use synthetic or redacted examples where personal data is unnecessary.

Keep the expected answer beside each test. “Looks good” is difficult to repeat next month. “Does not confirm availability without a calendar result” is something you can check.

Anthropic's guide to building effective agents makes a useful distinction between predefined workflows and agents that choose their own steps. It recommends starting with the simplest approach that works. A fixed review procedure may be enough for your first task; you do not need an agent making every decision.

Only add a schedule when the manual run is useful. Decide what should trigger action, how repeated items are handled and where failures appear. A daily check does not have to produce a daily email. Sometimes the right result is “checked, nothing changed.”

Write this brief before your next automation purchase

You can start with an ordinary document. Fill in these lines for one recurring task:

Job: What exact output do I want?
Inputs: Which approved sources should it use?
Limits: What must it never send, change or assume?
Check: How will I test the result?
Handoff: Who reviews it, and what happens next?

If the brief is difficult to finish, connecting more tools will not settle the missing decisions. Resolve one of them, run the task again and keep the result. That gives you something concrete to improve.

For the knowledge side, see internal AI assistants. If the task is ecommerce marketing, Lysterium Grow explains the managed-service offer and its boundaries.