You deployed the agent. It works.
Response latency is good. The context window is full. Tool calls are firing correctly. You've got retrieval augmented generation pulling the right documents. The output is coherent, the citations are accurate, and your QA pass rate is north of 95%.
And yet.
There's a pattern in the failure tickets you can't quite categorize. Not hallucinations — you've got that mostly under control. Not format issues — the templates are enforced. Something more subtle. The agent responds in ways that are technically correct but somehow wrong. Off-brand in a way that's hard to spec out. Ethically awkward in edge cases. Weirdly tone-deaf when a customer is clearly frustrated. Confident when it should be humble. Breezy when it should be serious.
You start stuffing more instructions into the system prompt. The failures get more specific. The system prompt gets longer. Some things improve. Others drift. You're playing whack-a-mole with judgment.
That is not a prompt problem. That is not a context problem. That is a values problem — and you don't yet have the infrastructure to solve it.
The Arc You've Already Lived
Let me back up.
Every builder who has shipped a serious AI application has lived through the same evolutionary arc. It just happened in a compressed three years instead of the decade it deserved.
Phase 1: Prompt engineering. This was the first act. You learned that how you asked mattered enormously. Chain-of-thought prompting, few-shot examples, role assignment ("You are a helpful expert in..."), structured output formatting. Prompt engineering was real, it was learnable, and for about eighteen months it was the highest-leverage skill in AI development. Then the models got better and a lot of that craft became unnecessary. By 2024, "prompt engineer" as a job title was fading. The models started doing a lot of the work themselves.
Phase 2: Context engineering. When Andrej Karpathy tweeted about "context engineering" in mid-2025, it went viral because it named something every serious builder had already discovered: the real leverage wasn't in the phrasing of the question, it was in what you put in the context window. RAG pipelines, structured memory, tool outputs, agent state, conversation history. The model's intelligence was already there — you just had to feed it the right information. Context engineering is still very much alive. It's the dominant paradigm right now. Most "advanced" AI architectures you see are sophisticated context management systems.
Phase 3: Values engineering. This is the act we're just entering.
The distinction matters:
- Prompt engineering is about how you ask.
- Context engineering is about what the model sees.
- Values engineering is about what the model cares about.
Those are three categorically different problems. The first two are solved — not perfectly, but well enough that they're engineering disciplines rather than research frontiers. The third one is still, to be blunt, largely unsolved.
Why Context Isn't Enough
This is where I need to push back on the dominant framing, because I think the AI infrastructure world is about to make the same mistake twice.
The assumption baked into context engineering is: if you give the model the right information, it will make the right decision. This is an epistemological assumption — a belief that correct behavior follows from correct knowledge.
It doesn't. At least, not reliably.
Here's why: behavior under tension — the interesting cases, the hard cases, the cases where your agent is actually earning its keep — requires more than information. It requires priorities. When honesty and kindness conflict, what does the agent do? When speed and thoroughness conflict? When a user's stated preference conflicts with what's actually in their interest?
An agent with perfect retrieval and no values hierarchy will make these calls however the model was trained to make them. Which means it will make them according to someone else's values — the training data, the RLHF process, the model provider's constitutional AI document. Those values might be good in the aggregate. They are almost certainly not your values, your users' values, or your company's values. Not precisely.
And context engineering doesn't fix this. Stuffing values statements into a system prompt doesn't fix this either — that's just prompt engineering with extra steps. System prompts are ephemeral. They don't persist across agents. They don't govern multi-agent flows. They don't surface the tension explicitly so it can be reasoned about and logged. They don't give you auditability when something goes wrong.
The agent that has read every document in your knowledge base and still makes the call that feels off — that agent has a context problem only if the thing it was missing was information. If what it was missing was priorities, you have a values problem. And you need a different layer in your stack.
What Values Engineering Actually Means
I want to be precise here because this term is going to get polluted fast once people start using it.
Values engineering is not:
- Fine-tuning for style. Fine-tuning bakes preferences into the weights. It's frozen at training time, model-specific, expensive, and not auditable at the individual decision level.
- Constitutional AI. Anthropic's work here is genuinely elegant — they got models to reason about principles during training. But it operates on the model, not on the deployment. You can't call Anthropic's constitution with your company's specific values at runtime.
- A longer system prompt. As I said: ephemeral, not governed, not auditable, breaks under adversarial pressure.
- Guardrails / safety filters. Those are blockers, not judgment. They say "don't cross this line." Values engineering says "here's how to navigate when you're nowhere near the line but the path still isn't obvious."
Values engineering is:
Runtime, not training. The values layer operates at inference time, per request, against the specific context of the conversation. The model is still the foundation — values engineering doesn't replace it. It's the application layer above the model that answers "given everything we know, what should we prioritize here?"
Explicit tension surfacing. Real values governance is about encoding trade-offs, not absolutes. "Honesty is important" isn't a values system. "When honesty and harm-avoidance conflict in a customer service context, lean toward honesty with compassionate framing" is the beginning of one. Encoded priorities. Named tensions. Explicit resolution logic.
Governance-grade auditability. When a regulated industry deploys an AI agent and gets a complaint, "the model decided" is not an acceptable answer. Values engineering means you have a log: here were the values in play, here was the tension, here's how the agent resolved it, here's why. That is what enterprise AI compliance actually requires, and it doesn't exist in most stacks today.
Portable across agents and models. Values shouldn't live in the model. They should live in infrastructure that any agent in your system can query. Multi-agent architectures — which are where everything is going — require values governance that spans agents, not just individual fine-tunes.
Configurable by humans who aren't ML engineers. The people who understand a company's values best are usually not the people training the models. Values engineering creates an interface layer that lets the right people — ethics boards, legal, brand, founders — actually participate in how the AI system behaves. Not by reviewing outputs after the fact, but by defining the judgment framework upstream.
The Next Job in the AI Stack
The pattern of AI stack evolution follows a clear progression: we solve the interface layer, then the knowledge layer, then the judgment layer.
Prompt engineering was interface. How do we communicate intent to the model?
Context engineering is knowledge. What does the model need to know?
Values engineering is judgment. How does the model decide when information alone doesn't determine the answer?
We are not done building until we've solved all three. And the third layer — judgment — is where the most significant failure modes live in production AI systems. The outputs that damage brands. The decisions that feel right by every metric and wrong by every instinct. The agents that are compliant and somehow still untrustworthy.
This isn't a philosophical problem. It's an infrastructure problem. And infrastructure problems get solved by people who think in systems, not people who tweak prompts.
TruContext: The Values Engineering Platform
If you've been nodding along, you already understand what needs to be built. The judgment layer isn't a feature — it's infrastructure. And infrastructure requires a deliberate architecture, not a better prompt.
TruContext was built on the premise that values should be infrastructure — not a prompt, not a training run, not a policy document uploaded to the context window.
The platform gives AI systems a persistent values layer: a structured substrate of priorities, tensions, and resolution logic that agents can query at runtime. The Values Oracle API returns alignment scores and judgment guidance on demand. The Human Context Graph encodes the tensions explicitly — not just the rules, but the trade-offs. The heartbeat system lets the values layer evolve as the organization's values evolve, without retraining.
We're calling this values engineering because that's what it is: the discipline of deliberately designing, encoding, and governing the judgment layer of AI systems. Not as an afterthought. Not as a system prompt. As infrastructure.
If you've shipped an agent and had that nagging sense that something feels off — not broken, not hallucinating, just subtly wrong — this is the layer you're missing.
Founding Developer Offer
TruContext is in active development, and we're building with a small cohort of founding developers who are willing to architect the values layer seriously.
The Founding Developer cohort gets:
- Direct access to the Values Oracle API and Human Context Graph primitives
- Co-design sessions on values schema and tension modeling for your use case
- Permanent founding developer pricing
- Input into the roadmap
We're not looking for people who want to evaluate a demo. We're looking for engineers and CTOs who have felt this problem in production and want to solve it properly.
Values engineering is the discipline that makes AI trustworthy, not just capable. The first builders to get this right will have a moat that can't be replicated by more compute or better models.
The layer exists. Time to build it.
References
- Karpathy, Andrej. "Context Engineering" [tweet]. X (formerly Twitter), June 2025. https://x.com/karpathy/status/1937902205765607626
- Albadri, Ahmed. "Prompt Engineering is Dead, Long Live Context Engineering." LinkedIn Pulse, 2025. https://www.linkedin.com/pulse/prompt-engineering-dead-long-live-context-ahmed-albadri-eokjf
- Krishnamoorthy, Priya. "From Dharma to Design." Medium, 2025. https://medium.com/@priya.krishnamoorthy/from-dharma-to-design-dfa814be9051
- "Beyond Prompt Engineering: Neuro-Symbolic-Causal Architecture for Robust Multi-Objective AI Agents." ResearchGate, 2025. https://www.researchgate.net/publication/397007037
- Buckley. "Prompt Engineering is Dead, Long Live Goal Engineering." BuckleyPlanet, October 2025. https://buckleyplanet.com/2025/10/prompt-engineering-is-dead-long-live-goal-engineering
- "Context Engineering vs. Prompt Engineering." Medium / Data Science in Your Pocket, 2025. https://medium.com/data-science-in-your-pocket/context-engineering-vs-prompt-engineering-379e9622e19d
- Bai, Yuntao, et al. "Constitutional AI: Harmlessness from AI Feedback." Anthropic, 2022. https://arxiv.org/abs/2212.08073