The RCT Framework: How to Prompt an LLM Like a Junior Intern

Most people who say “the model isn’t following my instructions” are not running into a model limitation. They’re running into a prompting failure. They handed the model five pages of instructions at once and expected an intern on day one to absorb it, prioritize it, and ship.

Ali Parandeh — chartered mechanical engineer turned AI engineer, head of engineering at a London AI consultancy, and author of Building Generative AI Services with FastAPI (O’Reilly, ~500 pages) — built generative AI services for cybersecurity, finance, retail, education, aerospace, and rail before writing the book on it. He uses a framework so simple it fits on one slide and so reliable he organizes most production system prompts around it.

He calls it RCT — Role, Context, Task.

The junior intern analogy is the whole framework

Before the acronym, there’s a mental model. Ali’s: treat the language model like a junior intern.

“There is a very ambitious, very attentive, and very motivated intern who’s just joined your company, who’s working for you, just for you, helping you like your best employee of the month assistant,” he says. “How would you describe tasks to them? You describe tasks to them in a way that helps them understand. It’s very clear and you do it step by step. And you don’t give them five pages of documents all at the same time.”

The junior intern frame does two things. First, it sets expectations — the model can deliver real work, but it needs the kind of scaffolding any new hire needs. Second, it kills the temptation to dump everything into one prompt. You wouldn’t hand an intern 500 pages and say “follow the instructions exactly by next week.” If you do that to an LLM, you get the same result: confused output, or worse, confident output that misses the point.

RCT — Role, Context, Task

The framework Ali uses is three components in order:

• Role. Tell the model who it’s playing. “You are an AI judge.” “You are a senior backend engineer reviewing pull requests.” “You are a customer support agent for a SaaS company.” This sets the persona, the tone, and the implicit knowledge base the model should draw from.
• Context. Give it the situation. What’s the surrounding information? What’s the user trying to accomplish? What does success look like? This is where most failures happen — engineers skip context because it feels obvious to them. It’s not obvious to the model.
• Task. State the specific thing to do. One task per prompt, ideally. If the task is complex, decompose it across multiple prompts or use chain-of-thought to make the reasoning explicit.

“It’s the easiest framework to start with,” Ali says. “But then you can also provide other prompt elements — what constraints does the model have? What output format do you want? Is there a tone you want the model to follow, like for your brand? Are there any examples you can give? Can you separate the instructions and the examples with delimiters?”

Once RCT is in place, you can layer in constraints, format specifiers, tone guidance, examples, and prompting techniques like decomposition or ensembling. But the order matters: get RCT right first.

What “context engineering” actually means

The industry has started talking about “context engineering” as a more rigorous discipline than prompt engineering. Ali’s framing is consistent with that. The model’s output quality is mostly a function of context quality — what you put in front of it before you ask the question.

“The more context you can give it, the more examples you can give it as part of it — here’s an example of how you should respond, or how I should process the output — the more you can explain the reasoning,” he says. “Crunch the data like this for me. Those things will essentially help improve the quality of the output and the alignment for you.”

Alignment, in Ali’s usage, means: did the model follow every instruction you gave it? It’s measurable. He suggests testing it the way you’d test an image generator — describe a dream house, request a giraffe in the middle, five helicopter pads on top, and see if the output actually has them. Same logic for text: did the model include every constraint, every output format requirement, every tone guideline? If not, the prompt was ambiguous, not the model.

Why this matters more for agents than for chat

The RCT framework is useful for one-shot prompts. It becomes essential for agents. AI agents — as Ali defines them — are system prompts with tools, memory, and data sources connected together. The system prompt IS the agent’s personality. If the system prompt is sloppy, every tool call the agent makes will be sloppy.

“Most of the time these days, the coding of AI agents will be essentially writing good system prompts,” he says. “There are resources on GitHub that have open-sourced the system prompts of existing tools like Chat GPT or Gemini that you can use to see how application developers have actually written system prompts for their models to be useful for users.”

The takeaway: if you’re building an agent, the highest-leverage engineering work isn’t the orchestration layer or the tool definitions. It’s the system prompt. Get RCT right there and most downstream problems disappear.

FAQ

What does RCT stand for in prompt engineering?

RCT stands for Role, Context, Task. It’s a three-part prompting framework Ali Parandeh teaches in Building Generative AI Services with FastAPI. Set the model’s role (the persona), give it the surrounding context, then state one specific task. RCT is the baseline; output format, constraints, and tone can be layered on top.

Why treat an LLM like a junior intern?

Because the intern frame produces better instructions. You wouldn’t dump five pages on an intern, expect them to prioritize correctly, or assume they understand unspoken context. Once you start writing prompts the way you’d brief a motivated new hire, the prompts get more specific, more scoped, and the model output gets dramatically better.

Should I give the LLM all my instructions at once or break them up?

Break them up. Long single-shot prompts produce confused output. Decomposition — splitting a complex task across multiple prompts — gives the model focused work at each step. Chain-of-thought prompting works similarly by forcing the model to think step-by-step inside one prompt. Either approach beats dumping everything in at once.

What’s the difference between prompt engineering and context engineering?

Prompt engineering optimizes the phrasing of a single request. Context engineering optimizes the information you put around it — examples, retrieved documents, user history, tool definitions. Context engineering is more rigorous because it treats the surrounding information as the primary lever for output quality. The prompt is the smallest part.

Does RCT work for agents and multi-step workflows?

Yes, especially for agents. An agent’s system prompt is essentially RCT scaled up — the role defines the agent’s personality, the context defines what it can do and what it knows, and the task is its goal. Multi-step workflows just chain RCT prompts together, with each step’s output becoming part of the next step’s context.

How long should a good system prompt be?

There’s no universal answer, but Ali’s heuristic is to scope the system prompt to one role with clear tasks. If you find yourself writing five pages of system prompt, that’s a sign you’re building multiple agents into one. Split it. Most production system prompts are a few hundred to a few thousand tokens, not pages.

What other prompting techniques pair well with RCT?

Chain-of-thought (asking the model to reason step-by-step before answering), decomposition (breaking a task across multiple prompts), few-shot examples (showing the model what good output looks like), and ensembling (asking the same question multiple times and comparing). Newer reasoning models do chain-of-thought under the hood, so you don’t always have to ask explicitly.

How do I know if a prompt failure is the model’s fault or my fault?

Most prompt failures are context failures, not model failures. Test by adding context — examples, format specifiers, explicit constraints — and see if the output improves. If adding context fixes it, the prompt was the problem. If the output is still wrong with maximum context, then the task is at the edge of the model’s capability and you may need a different model or a different approach.

Can junior engineers learn this faster than senior engineers?

Junior engineers often get RCT faster because they don’t bring assumptions about what the model “should” know. Senior engineers often skip context because the task feels obvious to them. The discipline is the same as briefing a new hire — and senior engineers who are good at managing junior engineers tend to be good at prompting.

Where can I learn more about prompting frameworks like RCT?

Ali Parandeh covers RCT and the broader prompt engineering landscape in Building Generative AI Services with FastAPI (O’Reilly), drawing on a literature review by the team behind learnprompting.org. The book includes comparison tables of techniques like chain-of-thought, decomposition, and ensembling, mapped to FastAPI implementations.