{"slug": "agentic-ai-in-action-part-30-prompt-engineering-vs-context-engineering-a-cortex", "title": "Agentic AI in Action — Part 30 -Prompt Engineering vs Context Engineering. A Cortex AI Walkthrough", "summary": "Context engineering, not prompt engineering, is the discipline that determines what fills a model's context window once teams build multi-turn agents that call tools and carry state, according to a Cortex AI walkthrough published as Part 30 of the \"Agentic AI in Action\" series. The post distinguishes single-turn prompt engineering — wording, structure, few-shot examples and formatting cues — from the broader practice of managing system instructions, tool definitions, conversation state, retrieved knowledge and tool output, illustrating the gap with a Cortex Agents helpdesk triage agent that must check enterprise contract status and prior tickets from account ACC-100, which carries a four-hour SLA and two prior tickets about a late dashboard refresh logged in the last month. The author argues prompt engineering remains necessary but becomes one component of the larger context engineering pipeline in agentic workflows.", "body_md": "Prompt engineering and context engineering solve different problems, even though the terms get used as if they were the same thing. Context engineering describes a real shift in where the hard work moved once teams stopped writing one off prompts and started building agents that run for many turns, call tools, and carry state across a conversation.\n\nThis post lays out the difference with concrete examples, including a couple pulled from the kind of Cortex Agent work I do day to day. The goal is not to declare one discipline obsolete. Prompt engineering still matters. It just stopped being the whole job.\n\nPrompt engineering is the craft of writing the instruction that goes to the model in a single turn. It covers wording, structure, few shot examples, and formatting cues. Done well it reliably improves output for a bounded task where everything the model needs fits inside one well worded request.\n\nA simple example. Asking a model to summarize a support ticket works better with a structured instruction than a vague one.\n\n*Summarize the ticket below in three sentences. Include the customer’s core complaint, any troubleshooting steps alreadyattempted, and the requested resolution. Do not invent steps that werenot mentioned.*\n\n*Ticket: {ticket_text}*\n\nThat is prompt engineering doing its job well. The instruction is specific about format, scope, and what not to do. For a single call with all the information already in front of the model, this is often enough.\n\nThe moment you build an agent that has to remember earlier decisions, pull from a knowledge base, call a tool, and act on the result, a better worded prompt cannot fix what is missing. If the ticket text was never retrieved, or the retrieval pulled the wrong document, no amount of prompt polish recovers the answer. The problem has moved from how you ask to what the model has in front of it when you ask.\n\nThis is the gap context engineering fills. It is the discipline of designing and managing the entire information environment around the model rather than just the instruction. That environment typically includes the system instructions and tool definitions, the task and conversation state built up so far, retrieved knowledge from documents or databases, and the output of any tools already called. Prompt engineering happens inside that context window. Context engineering decides what fills the window in the first place. While prompt engineering works perfectly on its own for simple, single-turn tasks, building agentic workflows subsumes it into the much larger pipeline of context engineering. In such systems, prompt engineering becomes just one component of the larger context engineering ecosystem.\n\nTake a helpdesk ticket triage agent built on Cortex Agents. A prompt only version of this agent gets a system instruction describing the triage policy and the ticket text, then asks the model to classify severity and route it.\n\nThat works until the agent needs to check whether the customer is on an enterprise contract before deciding severity, or needs to search for prior tickets from the same account to catch a repeat issue. At that point the design question is no longer about phrasing. It becomes which tools the agent has access to, what is exposed about account tier and ticket history, how much of that history gets pulled into context before it becomes noise, and how the tool’s structured output gets folded back into the next reasoning step.\n\nWalking through it step by step makes the difference concrete.\n\nA dedicated database ansd schema for maintanability.\n\nOne table for tickets, one for accounts.\n\nThe Accounts table has two entries. However, for this demonstration, we will consider the enterprise customer (ACC-100) on a four hour SLA, with two prior tickets about the same dashboard refresh running late, logged in the last month besides the one just opened.\n\nJust the ticket text and an instruction, nothing else. The instruction includes an explicit escalation rule, since handing the model facts without telling it what to do with them turned out not to be enough on its own.\n\nThree things worth flagging in that call. First, the temperature setting. Like most LLM inference, results can vary slightly run to run unless temperature is fixed, so setting it to 0 keeps this comparison deterministic and reproducible. Second, the prompt is wrapped as a single user message rather than passed as a bare string, since the three argument form of Complete that accepts an options object expects a message array for the second argument, not a plain string. Third, once that options argument is present, Complete returns an OBJECT rather than a plain string, with the model’s actual answer nested under choices[0].messages. Path directly into it, do not wrap it in PARSE_JSON, since it is already a parsed OBJECT and not a string to be parsed.\n\nThe escalation rule is in the instruction, but the only field available to test it against is ticket_text. There is no occurrence count and no SLA figure here, so the rule has nothing to fire on.\n\nSo, it evaluates the nature of the ticket purely as a standalone issue based on the prompt text, and without any additional context, ultimately marking it as low.\n\nActual output returned for this ticket:\n\nFirst pull together what the prompt alone could never see, account tier, SLA hours, and how many times this account has filed a similar ticket in the last 30 days. That last part matters enough to compute directly in SQL rather than leave for the model to work out by reading a block of ticket history, since asking a model to parse text and count occurrences in one pass is asking it to do arithmetic on unstructured input, and it does not reliably get that right.\n\nActual output for the same ticket, with the assembled context in front of it.\n\nNotice how the output has changed when the complete picture is available. Same escalation rule in both steps. The severity call flips from LOW to HIGH, and what changed between step 2 and step 3 is not just that more facts got added to the context, it is that the fact the rule actually depends on, the occurrence number, got computed upstream in SQL instead of left for the model to derive from raw text. That distinction, what gets precomputed versus what gets handed over raw and left for the model to reason about, is a context engineering decision in its own right.\n\n*In a real Cortex Agent deployment, the account tier, SLA hours, and recent history assembled by hand in step 3 would typically be exposed through a Semantic View instead, so the agent queries a governed, reusable definition rather than ad hoc joins baked into each call.*\n\nIt is also worth being clear that the demo folds everything into a single query for the sake of a runnable example and ease of understanding. In a live agent, that same context could often arrive from several separate tool calls, one for account tier, one for SLA terms, one for ticket history, sometimes backed by different systems entirely, and it is the agent’s job to assemble those separate results into one coherent context before the final classification step. The comparison in this post is never prompt versus a single query. It is prompt versus everything the agent gathers and assembles before it answers (the context), however many calls that takes.\n\nThe same agent extended with tools runs into a related problem. Say it also has access to search_prior_tickets and get_account_tier as separate tool calls. If those two tools overlap in what they return, or their descriptions do not make clearly which one to call for which piece of information, the agent can call the wrong one, or call the right one but pass it the wrong ticket or account identifier. The instinct is to rewrite the tool descriptions to be clearer. Sometimes that helps. More often the actual cause is that the tool set itself is ambiguous, two tools doing overlapping jobs, or that the context already in front of the agent buries the identifier it needs to call the tool correctly under unrelated history.\n\nThe fix is curation, not better wording. Keep each tool narrow enough that its purpose is unambiguous, and keep the context in front of the agent limited to what the current decision actually needs, rather than everything retrieved so far. Measuring tool selection accuracy separately from the accuracy of the final answer is what tells you whether a given failure sits in how the tool is described or in what the agent had in front of it when it chose.\n\nPrompt engineering and context engineering are not competitors. Prompt engineering operates at the interaction level, refining how you ask a single question well. Context engineering operates at the infrastructure level, deciding what the agent knows and can act on before it ever answers. A useful way to hold both at once is this. Prompt engineering is what you do inside the context window. Context engineering is the discipline of deciding what belongs in that window and what gets left out.\n\nFor anyone building agents rather than single turn assistants, the practical shift is to stop treating every failure as a wording problem. Before rewriting the system prompt again, it is worth asking whether the agent actually had the right document, the right tool, and the right slice of history in front of it when it produced the wrong answer. If it did not, no prompt could have fixed that.\n\nThe code for this blog can be accessed [here.](https://github.com/Krishsriniv/prompt-vs-context-engineering)\n\n*I share hands-on, implementation-focused perspectives on Generative & Agentic AI, LLMs, Snowflake and Cortex AI, translating advanced capabilities into practical, real-world analytics use cases. Do follow me on* *LinkedIn* *and* *Medium* *for more such insights.*\n\n[Agentic AI in Action — Part 30 -Prompt Engineering vs Context Engineering. A Cortex AI Walkthrough](https://pub.towardsai.net/agentic-ai-in-action-part-30-prompt-engineering-vs-context-engineering-a-cortex-ai-walkthrough-0a8b8704f2b8) was originally published in [Towards AI](https://pub.towardsai.net) on Medium, where people are continuing the conversation by highlighting and responding to this story.", "url": "https://wpnews.pro/news/agentic-ai-in-action-part-30-prompt-engineering-vs-context-engineering-a-cortex", "canonical_source": "https://pub.towardsai.net/agentic-ai-in-action-part-30-prompt-engineering-vs-context-engineering-a-cortex-ai-walkthrough-0a8b8704f2b8?source=rss----98111c9905da---4", "published_at": "2026-09-30 17:31:02+00:00", "updated_at": "2026-09-30 17:47:38.203921+00:00", "lang": "en", "topics": ["ai-agents", "large-language-models", "ai-tools", "artificial-intelligence"], "entities": ["Cortex Agents", "Cortex AI", "ACC-100"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/agentic-ai-in-action-part-30-prompt-engineering-vs-context-engineering-a-cortex", "markdown": "https://wpnews.pro/news/agentic-ai-in-action-part-30-prompt-engineering-vs-context-engineering-a-cortex.md", "text": "https://wpnews.pro/news/agentic-ai-in-action-part-30-prompt-engineering-vs-context-engineering-a-cortex.txt", "jsonld": "https://wpnews.pro/news/agentic-ai-in-action-part-30-prompt-engineering-vs-context-engineering-a-cortex.jsonld"}}