Writing the agent is writing the prompt and the policy.

Part 6 asked where agents fit. This part is design time: two documents that have to agree. The prompt is what the model is told (goal, scope, stop). The policy is what the runtime allows (tools, identity, approvals). A vibe in a chat box is neither.

Evaluation and rollout wait until Parts 8 and 9. If you skip this pairing, those chapters are theater.

AI Right Now Part 6 named the instinct — what it may touch. Here we encode that instinct as spec.

Prompt engineering: a job spec, not a personality

Production prompt engineering is not a bag of clever phrases. It is a versioned job description the model can be graded against:

  • Goal — one checkable outcome (“draft a PR that makes test_invoice.py pass”)
  • In scope / out of scope — what it must never attempt
  • Stop conditions — max steps, max spend, max emails, “ask a human”
  • Owner — a named team, not “the AI”

The system prompt is the first draft of that spec. Treat it like production config: versioned, reviewed, boring.

Tool descriptions are prompts too. “Run any SQL” teaches the model that the world is an admin console. get_invoice(id) teaches a job. If you change a tool name or argument, you changed the prompt. Review them together.

A vibe prompt sounds friendly and unbounded: “You’re a helpful finance assistant. Use any APIs you need.” A spec prompt names the outcome, the refusals, and the stop. Same model. Different product.

Tools are the real permissions

The model only asks. Your runtime does. So the allowlist is the product — and it is the layer a prompt cannot override:

  • Name each tool. Describe it for the model and for security review.
  • Pass the minimum arguments. A run_sql that accepts any string is an admin console. A get_invoice(id) is a tool.
  • Separate read from write. Separate “draft” from “send.”
  • No credentials in the prompt. The runtime injects secrets the model never sees.

Least privilege is your friend. It is which functions you register. A perfect system prompt with an open toolbelt is still an open toolbelt.

Policy: write the rules the loop must obey

Policy is the written layer above tools: who the agent acts as, what data classes it may see, when a human must approve, what “break glass” looks like. The prompt should repeat those rules in language the model can follow. The policy is what you enforce when it does not.

The NIST AI Risk Management Framework is a voluntary public map for that work — govern, map, measure, manage — including design, not only incident response. You do not need to adopt NIST by name. You do need the same questions on paper before the first tool call in production.

A useful policy page is one screen:

Question Example answer
Identity Acts as user with id: invoice-agent, not as a shared admin
Data Invoice metadata; no PAN, no HR files
Writes Create draft tickets only
Approval Human clicks send
Audit Every tool call logged with args and result

If you cannot fill the table, you are not ready to write the production prompt. You are ready to prototype in a sandbox with fake data.

Example

Bad (vibe): “You’re a helpful finance assistant. Use any APIs you need.”

Good (spec + policy): system prompt = unmatched invoices older than 14 days, draft tickets only, stop after 20; tools = list_unmatched, create_draft_ticket; policy = no payments, no customer email, human send.

Same model. Different company.

Conclusion

Prompt engineering and policy are one act. The prompt is the spec the model sees. The policy is the spec the runtime enforces. Tomorrow we prove both with evals and tests. Version the instructions and write the allowlist.

Takeaway: An enterprise agent starts as a versioned prompt plus a written policy.

Sources

Part 6: Where Agents Actually Make Sense
Part 8: Evaluation and Testing