How to design AI-native apps by exposing the system prompt to users

Executive overview

Most AI features feel like more work than they save because developers hide the system prompt — making AI a generic, one-size-fits-all tool rather than one the user can teach. The Gmail email-drafting agent illustrates this: it produces safe, businessy output that sounds nothing like the person sending it.

Letting users see and edit the system prompt turns AI from a feature bolted onto legacy software into something users can programme in plain English. Coupling that with the right tools — actions the agent can take in the world — is how AI shifts from Q&A chatbot to genuine work automator.

The core insight: AI apps should let users teach the machine how they think, not force every user through the same lowest-common-denominator behaviour.

The system prompt problem

• The Gmail draft agent combines a fixed, hidden system prompt with each user's prompt — the system prompt always wins on tone.
• The hidden prompt is optimised for safety and brand protection, not for sounding like the individual user.
• This produces output that is correct but impersonal — the prompt to request the draft is often as long as the draft itself.
• Treating the system prompt like proprietary code is a legacy software instinct: developers own the logic, users just click the interface.
• The result is lowest-common-denominator software: nobody gets fired, but nobody uses it either.

The AI horseless carriage

• Early automobiles looked like horse carriages with an engine swapped in — the new power source required redesigning the whole vehicle.
• The same pattern recurs across technology shifts: early search engines were digitised yellow pages; early mobile apps were websites in a native wrapper.
• Most AI features today slot AI into applications designed for humans to do the work — they replace the horse but keep the carriage.
• The right question is not "how do I insert AI into my product?" but "how would I design this tool from scratch to offload repetitive work?"

What exposing the system prompt enables

• A user-written system prompt (e.g. "You're Pete, 43, busy, keep emails as short as possible") produces output that sounds like the actual user.
• The system prompt is the user's internal decision algorithm, written once and reused every time — eliminating the need to re-explain preferences in each prompt.
• Because it is plain English, it is readable and editable by non-developers; writing it is intuitive once you can observe the agent's output and adjust.
• Showing the prompt also surfaces what the agent has been instructed to do — eliminating the black-box problem that plagues memory features in existing chatbots.

Tools: from Q&A to work automation

• Tools are the actions an agent can take in the world (label an email, archive it, write a draft, BCC someone).
• Without tools, an LLM agent is just a question-answering interface; tools turn it into something that accomplishes tasks autonomously.
• An email-reading agent with the right tools can triage, label, draft replies, and handle transactional emails — freeing the user for the few messages that require real thinking.
• Chaining tools across services (Slack, calendar, Google Docs, GitHub) via MCP servers enables multi-step workflows controlled from one place.
• Developer tools like Cursor and Windsurf are ahead because they expose full model access and don't apply the same liability-driven guardrails as consumer apps.

Who will write system prompts — and how

• Today, most users cannot write system prompts; in the near future, most will be able to — just as using a computer shifted from a specialist skill to universal literacy.
• Prompting is more accessible than operating a file system: if you can explain how you make a decision, you can write the prompt.
• The practical workflow is iterative: watch the agent run, spot what's wrong, adjust the prompt, repeat.
• A better abstraction sits above raw prompt editing: users give feedback ("I would have phrased it this way") and the AI auto-updates the system prompt on their behalf.
• At scale, 20 years of email history could bootstrap a personalised system prompt without the user writing a word; explicit editing becomes a break-glass option, not the default path.

Implications for founders

• Almost every existing tool can be redesigned from the ground up as an AI-native product.
• The AI-native version looks substantially different from its predecessor — not a chatbot bolted on, but a product where the agent does the repetitive work and the user focuses on what matters.
• Liability for model output shifts when the user controls the system prompt: if the user changes the instructions, the consequences are on the user, not the developer.
• Every domain will have its "Cursor moment" — when non-programmers can build and teach agents to handle their repetitive workflows in natural language.