System prompts, agents, tools & delegation

The concept

A chat prompt is a request: it applies once and then it's gone. A system prompt is a job description: it applies to every message in that agent's life, sets its standing behaviour, and the agent cannot see around it. You already run a fleet of agents, so this is the module with the most direct operational payoff — the difference between an agent that needs constant supervision and one that just works is almost entirely the quality of its system prompt.

The key mental shift: when you write a chat prompt you're briefing a task; when you write a system prompt you're hiring a person and writing their contract. You specify who they are, what they're responsible for, what they're forbidden to do, how they report, and what to do when they're stuck. Everything you'd tell a new employee in week one belongs in the system prompt — not repeated in every message.

What a good system prompt contains

1. Identity and scope. Who the agent is, who it works for, what it is not. ("You are X, assistant to Y. You are not Y — never impersonate him.")
2. Standing behaviour and defaults. Language, length, tone, formatting. Set the default so you don't restate it 400 times.
3. Authority and boundaries. What it may do alone, what needs confirmation, what it must never do. Be explicit and enumerate — "use good judgement" is not a boundary.
4. Capabilities and tools. What it can actually reach, and — just as important — what it can't, so it stops proposing things it can't deliver.
5. Escalation rules. What to do when blocked, uncertain, or out of scope. Without this, agents either freeze or improvise.
6. Reporting format. How results come back to you. This is where most agent fleets leak time: an agent that reports in the wrong shape makes you do work.
7. Concrete examples of good and bad behaviour. Few-shot works on system prompts too, and one worked example beats a paragraph of principle.

Rules that separate working agents from toys

• Positive instructions beat prohibitions. "Reply in under 5 bullets" works better than "don't be verbose." Prohibitions still matter for hard limits, but always pair them with the desired behaviour.
• Enumerate, don't generalise. "Confirm before: deleting files, sending external email, spending money, changing DNS" beats "confirm before dangerous actions."
• State the failure behaviour. "If a tool errors, retry once with a different approach, then report the exact error. Never report success you haven't verified." Agents that don't have this rule will tell you a thing is done because it should have worked.
• One agent, one job. A specialist with a tight system prompt outperforms a generalist. Delegation across several narrow agents beats one agent with a 40-page brief.
• Order the document by priority. Put the non-negotiables at the top and repeat the truly critical ones at the bottom. Middle-of-document instructions get followed least.
• Version it. Date every change. When behaviour degrades you need to know what you altered.

Delegation: the part most people get wrong

When you hand a task to a sub-agent or a background worker, it starts with no memory of your conversation. Everything it needs must be in the handoff. The most common failure in an agent fleet isn't a bad model — it's an under-briefed delegation. Your handoff should contain: the goal (not just the step), all context, the definition of done, the output format, and what to do if it can't finish.

And a rule for you personally: delegate anything that takes longer than about a minute, so the main thread stays available for you. Fire-and-forget work belongs in a queue; work where you'll react to intermediate output stays in the live conversation.

Before → After

You are a helpful assistant for Strike Media. Help with marketing
tasks and be professional.

IDENTITY
You are the Strike Media content agent. You draft social and campaign
copy for our clients. You are not a client-facing account manager and
you never send anything externally — you produce drafts for human
review.

DEFAULTS
- Match the language of the request (Arabic → Arabic, English → English).
- Arabic register: written Egyptian unless the brief says formal.
- No preamble. Start with the deliverable.
- Always give options in odd numbers (3, 5, 7), never a single option.

CLIENT VOICE
Before drafting for any client, read memory/voice-<client>.md and apply
those rules. If that file doesn't exist, say so and ask for 3 approved
samples before drafting.

HARD RULES
- Never invent a statistic, price, date, or client claim. Use
  [PLACEHOLDER] and flag it.
- Never use an emoji unless the client's voice file allows it.
- Never write Arabic that reads as translated from English. Forbidden
  constructions: نحن نقدم لكم / في عالم اليوم / من خلال / يعتبر.

ESCALATION
If the brief is missing audience, objective, or channel — ask up to
3 questions before drafting. Do not guess.
If a request involves pricing, contracts, or a public statement on
behalf of the agency — refuse and route to MFZ.

REPORTING FORMAT
## Draft options
[numbered]
## What I assumed
[bullets — anything I filled in myself]
## What I need from you
[bullets, or "Nothing."]