How to Build a System Prompt & Tool-Calling Agent

A system prompt is the part of an agent's input that never changes between requests. It tells the model who it is, what it is trying to do, what it knows, what it must not do, and what its answers should look like. When it is well structured, a modest system prompt does more than a page of vague instructions — and when it is disorganized, the model improvises in all the wrong directions.

Start with the role. A single sentence that names the persona — "You are a senior data analyst" — anchors everything downstream. The role is the lens through which the model interprets every other instruction, so be specific enough that the persona is usable but not so theatrical that it distracts. "You are a Python assistant that writes concise, dependency-free snippets" outperforms "You are a brilliant coding genius."

Then state the goal. The goal is what the model should achieve on every call, phrased as an outcome, not a process. "Given a user request, produce the requested answer and, when useful, call the available tools." The goal answers the question the model will ask constantly: what am I here for? Write it plainly and place it near the top so it is always in the model's early attention window.

Provide context. Context is the stable knowledge the model needs that is too long to repeat per request, or too sensitive to rely on the user to provide. It can be a style guide, a product description, a list of conventions, or a short data dictionary. Keep it scannable — bullets beat paragraphs — because the model will weigh every word in context, and buried instructions behave like weak hints.

Declare constraints. Constraints are the boundaries: what the model may not do, when it should refuse, how it should handle unclear input. "Never invent data; say 'unknown' instead." "Do not apologize." "Only use the tools listed below." Constraints work best as short negative rules, and they should match the tools you actually expose — an instruction to always use a database tool fails if the tool is not available.

Specify the output format. If every answer should be JSON, say so and show the shape. If answers are prose, say how long and at what reading level. The output format is a constraint the model honors far more reliably when you demonstrate it than when you describe it abstractly — one example of a valid output is worth three sentences of specification.

Declare tools as a contract. Tool-calling agents receive a list of tools, each described by a name, a description, and a parameter schema. The description is what the model uses to decide when to call a tool, so write it in terms of outcome — "search for a merchant by name, returns match confidence" — not implementation details. The parameter schema must match exactly what your handler expects; a mismatch produces calls your code cannot serve.

The builder on this page assembles these five sections into a single copy-ready system prompt and emits a JSON tools array. Writing by hand, it is easy to forget a section or leave a constraint only half-stated; the structured form makes the prompt complete before it ever reaches the model. Both exports are plain text and JSON, so they drop straight into your code, your config file, or your favorite model playground.

Finally, treat the system prompt as living code. Version it, test it against representative requests, and review the generated prompt in full before deploying. The difference between a toy agent and a reliable one is rarely a cleverer model — it is a system prompt that has been edited, measured, and trimmed until every sentence earns its place.