I used to think AI was unreliable. I’d write a prompt, get something vaguely in the right direction, tweak it, get closer, tweak it again, and after three or four rounds I’d finally have something usable. It worked, but it was expensive and exhausting. The model hadn’t changed between attempts. My goal hadn’t changed. So why did the same prompt produce brilliant architecture one day and useless fluff the next?
That question bugged me enough to start studying not just the outputs, but the thought processes behind them. I traced how the model reasoned its way from my instructions to its response, and compared the prompts that landed with the ones that didn’t. After a while, the pattern became impossible to ignore. It wasn’t the model’s fault. It was how I was talking to it.
The same way I learned to write clearly for humans through years of reading and writing, I needed to learn to articulate for machines, not in code, but in structure, in clarity, in intent. Four elements kept surfacing in the prompts that worked consistently: Role, Intent, Context, and Expectations. I called it RICE.
Why RICE works
RICE forces you to articulate what you actually want at a level of detail a machine can act on, and the side effect is that it makes you think more clearly about what you’re asking for.
- It saves money. Every vague prompt means more iterations, more tokens, more time spent refining an output that could have been right the first time.
- It prevents the AI from making its own decisions. Without clear articulation, the model fills the gaps with guesses, and those guesses compound into a result that’s close to what you wanted but never quite there. RICE closes those gaps so the AI executes what you intended, not what it assumed. In other words: RICE reduces variance rather than guarantees correctness.
- It works everywhere. RICE is not a strict checklist. You choose and combine the elements and attributes that fit your specific ask. Some prompts need deep context and minimal expectations. Others need a precise role and a clear intent. The framework adapts to what you’re building, and scales from quick prompts to long-running projects.
- It works for everyone. Engineers get precise, reproducible outputs. Executives get faster results without needing to understand how the underlying technology works. Organizations can share effective prompt patterns instead of everyone reinventing their own approach.
The teams I’ve seen fail with AI didn’t fail because the technology wasn’t ready. They asked vague questions, got vague answers, and concluded AI was useless. With the right structure, it’s remarkably reliable. Not perfect, but predictable enough to trust.
The Four Elements of RICE
To make it easier to talk to AI, I imagine myself onboarding a new hire for a specific task whose success depends entirely on the clarity and completeness of my instructions. RICE consists of four elements, each with their own attributes, that help me formulate instructions an agent can actually execute.
R is for Role
Every new hire is given a role, and every good prompt starts the same way: establishing who the AI agent is. Not just a job title, but a well-defined identity with the right boundaries and perspective.
A vague role makes the AI default to generic patterns. It won’t know whether to answer like a mid-level developer or a chief architect, whether to prioritize speed or accuracy, whether to assume enterprise or consumer context. Every one of those choices changes the output.
A well-defined role covers expertise, domain, and capabilities. Get it right and everything that follows has a solid foundation.
Expertise and seniority
An agent should know what level it operates at.
A weak role prompt says:
“You are a software engineer, write a function to handle user authentication.”
A strong one says:
“You are a senior backend engineer with over a decade of experience building authentication systems, with deep knowledge of OAuth 2.0, JWT, and session management patterns.”
The level matters. A junior engineer and a senior architect produce fundamentally different outputs for the same task.
Domain constraints
It’s important to define the boundaries the agent should not cross, like a new hire who joins a specific business unit or team.
“You are a platform architect in the energy sector. Your expertise covers Azure cloud services, Kubernetes, and enterprise integration patterns. Do not provide guidance on data center hardware, network engineering, or security operations.”
Boundaries keep the AI focused on what’s relevant to you. Without them, it defaults to generic patterns that don’t fit your domain.
Capabilities
An AI agent must be told where its capabilities lie, else it will start making its own decisions to fill the gaps.
“You are a frontend engineer skilled in Next.js 15+, Tailwind, and TypeScript. You follow a component-driven development workflow and you have access to a design system reference for UI patterns and accessibility standards.”
Specific skillsets constrain the AI’s approach to what actually works in your environment.
Putting it all together
“You are a senior enterprise architect at a large European telecom company. You specialize in business and application architecture, with deep experience in Azure cloud services, AI platform engineering, and enterprise integration patterns. You have worked extensively with the TOGAF framework and have practical experience building platforms in the energy and telecom sectors.”
And from another perspective:
“Assume the role of an executive advisor specializing in AI-driven transformation for large enterprises. Your experience spans the energy, telecom, and financial services sectors. You communicate complex technical concepts clearly to C-suite leaders without dumbing them down.”
I is for Intent
Unless the new hire knows what they are hired to do, their experience and expertise won’t be enough. Intent answers what you want to accomplish, and the most common mistake is stopping at a surface-level description that leaves too much room for interpretation.
A strong intent has two layers: the goal, and the depth of the ask.
Goal
What do you want, exactly? Unless you know what you want, the agent won’t know what to do.
“Convert this Excel spreadsheet into a functional dashboard that can be presented as a high-level operational report to the top execs in the organization.”
That’s a start, but vague enough that the AI could produce anything from a simple table to a full analytics suite. What will the dashboard contain? Should it be a one-pager? Should users just consume it, or interact with it? This is where depth and specificity come in.
Depth and specificity
“Convert the Excel spreadsheet into a working dashboard with both a summary view showing high-level KPIs and a detailed drill-down view for each individual data point. The summary should highlight trends and anomalies. The detail view should show the raw data with sorting and filtering.”
The simple prompt gives you something. The deeper one gives you what you actually want.
Audience
Who is this for? The same intent produces different outputs depending on the audience. A dashboard for the executive team emphasises KPIs and trends. A dashboard for the engineering team emphasises raw data and drill-downs. The audience shapes the tone, the level of detail, and what the AI chooses to highlight.
“Create a summary of this incident report for two audiences. For the executive team: focus on business impact, timeline, and resolution. For the engineering team: focus on root cause, technical details, and remediation steps.”
“This documentation is for new developers joining the team. Assume no prior knowledge of our internal systems. Explain concepts from first principles. Include setup instructions and common troubleshooting steps.”
Putting it all together
Here’s an example for Business Analysts:
“Create a PRD for a new internal AI assistant platform. The document should cover the business case, technical architecture options, implementation roadmap, and risk assessment. It needs to be detailed enough for engineering to estimate effort, but structured so leadership can make a go/no-go decision.”
And another, for the techies:
“Design and implement a user management microservice that handles registration, authentication, authorization, and profile management. The service must support OAuth 2.0 and SAML-based single sign-on, provide REST and gRPC APIs, and include rate limiting, audit logging, and integration tests. Deliver a complete PRD, an OpenAPI specification, and a working service deployed to our Kubernetes staging environment.”
One more, for the execs:
“This presentation will be delivered to an executive leader who has genuine interest in AI but limited hands-on experience with coding tools. Frame everything around strategic value. They need to see the business outcome, not the implementation details.”
C is for Context
Context is where the quality of the output is decided. It expands the what, and answers the why, the why not, the how, and the how not.
Think about onboarding a new hire again. You’ve told them their role and what they need to do, but they still have a hundred questions. Where do I find the documents? What systems can I touch? What does the schema look like? What happens if I get it wrong? Most prompts skip these questions entirely, leaving the AI to fill the gaps with assumptions that are often wrong.
Good context covers five areas: source, workflow, impact, consequences, and guardrails.
Source
Tell the agent where to get the information it needs, otherwise it will wander.
“Connect to the PostgreSQL database at db.example.com using the credentials in the .env file. Read the schema from the public schema only.”
Workflow
How do we do things around here?
“Follow the existing CI/CD pipeline. Commit to develop first, then create a PR for review. Do not deploy directly to production.”
Impact
Why does this matter? Adding impact to the context reinforces the success mentality in the agent and focuses its thinking.
“This dashboard will be presented to the executive team. The accuracy of the data directly affects our Q4 investment decisions.”
Consequences
What happens if the results are inaccurate? Defining negative consequences reinforces the right path.
“A data leak would be a critical incident, loss of customer trust and regulatory fines. Guard all PII fields. If you’re unsure, ask rather than assume.”
Guardrails and constraints
What should the AI never do? This is perhaps the most important attribute of context.
“You are to work only within the /src directory. Do not modify any file outside it. If a file must be changed elsewhere, flag it and stop.”
Bringing it together
“Connect to the production-read-replica PostgreSQL at prod-replica.internal:5432 using the service account credentials. Read the orders schema only. This report goes to the board. Every number must be accurate to two decimal places. All changes go through feature branches with two approvals. Never expose customer PII. Never query the primary production database. This report is subject to GDPR compliance.”
E is for Expectations
What does done actually look like? Without expectations, the AI doesn’t know what the final deliverable should be, or when to stop working. You won’t know when to stop reviewing either.
Expectations cover four things: artifacts, format, examples, and action.
Artifacts
The tangible result of the task. What do you want at the end?
“A container image pushed to our Azure Container Registry.”
“A set of Jira tickets with description, acceptance criteria, and story points.”
“A deployment script for the staging environment.”
Format
What form should the output take?
“A markdown file for the PRD.”
“A PDF for the architecture document.”
“The dashboard must be a single-page HTML application with embedded CSS and JavaScript.”
Examples
Sometimes the best way to communicate what you want is to show it. Provide existing examples to steer the agent in the right direction.
“Here is an example of a well-structured PRD from a previous project. Use it as a reference for tone, level of detail, and section structure.”
“Refer to the design images in the /references folder, and recreate them in HTML. Make sure to keep the general look and feel, including the layout and the typography, but the approach should be modern.”
Action
What to do with the artifact once it’s ready?
“Deploy the dashboard to Vercel.”
“Store the documents in the /docs folder.”
“Send a summary to the team Slack channel.”
Bringing it together
“I want a proof-of-concept application deployed to a publicly accessible URL. Deliverables include a running frontend, a REST API with Swagger documentation, a deployment guide in markdown, and a 10-slide executive summary PDF. Reference the project structure from our existing auth-service repository. Deploy to staging and notify the team in Slack.”
The real lesson
I’ve been using RICE for months now, and it’s saved me time, money, and a lot of frustration. More importantly, it’s made me trust the output enough to rely on it. Not blindly, but predictably.
That’s the thing I keep coming back to. The bottleneck isn’t the model. It’s how we talk to it.
Resources
Want to try out RICE yourself? You can write the RICE prompt yourself now, but here are some materials that might help you get more out of the framework:
- RICE Website
- Agent Skill (AGENTS/CLAUDE.md instructions, skills, system prompts, etc.)
- Reusable template (copy/paste)
- RICE-conversion prompt (to transform a prompt to RICE-compliant prompt)
They are all copiable and downloadable from my RICE GitHub repository.
You can also see how I use RICE myself in the original blog post.
If you’re working with AI agents and want to think through prompting strategies, architecture, or how to get your team better results, I’d love to connect. Reach out at zulmehdi.com or find me on LinkedIn.
