Most conversations about AI agents still center on which model to use. The more interesting conversation, increasingly, is about what surrounds the model: what data it can see, what tools it can call, and what it's allowed to say. That shift, from picking a smarter model to engineering a smarter environment around it, is what's usually meant by context engineering AI agents, and it's the through-line of a recent conversation on The AI Native Dev with Ori Shoshan, tech lead at Cyera.

Shoshan leads AI adoption at Cyera, a data security company, having joined through Cyera's acquisition of Otterize, which he co-founded with Tomer Greenwald. His path into agent building started somewhere unusual: his living room, in January 2026, wondering why he was still doing tasks on his phone by hand when an agent could plausibly do them for him.

Why Whitelisting Tools Beats an Open Check

Shoshan's first instinct was to reach for an assistant with broad, unrestricted access, something in the spirit of early "does everything" agent tools. He decided against it. "It felt very uncontrolled and just a disaster waiting to happen," he explained, arguing that an LLM in an agent harness with an open check to do anything will eventually do something it shouldn't. "It's just like evolution," he noted. "They will explore that path if it's there."

His fix was to whitelist tools rather than blacklist behavior: give the agent a wide but explicitly defined set of capabilities, and withhold the one tool, a general-purpose bash shell, that would let it do anything at all. In practice this means an agent might have access to dozens of specific tools (Cyera's agents have settled around 60), but never an unconstrained escape valve into arbitrary code execution.

One detail worth noting for anyone building this pattern: Shoshan always leaves the agent an explicit "escape hatch," a tool for flagging that it wanted to do something it couldn't, rather than silently attempting a workaround. Without that hatch, he pointed out, a model might quietly try to accomplish its goal some other way, a failure mode that's easy to miss unless you're reading its reasoning traces closely.

From Prose to Citations: Context Engineering vs Prompt Engineering in Practice

Context engineering, in the sense Ori Shoshan uses it, is the discipline of deliberately shaping what an AI agent can see, in what structure, and from what source, so that its output becomes both more reliable and easier to verify after the fact, rather than trusting a longer prompt alone to produce good results.

Rather than letting an agent produce a wall of prose, Shoshan's platform forces every claim into a structured block: a claim, paired with a source reference. If the model can't back a statement with a source, it has to mark it explicitly as opinion.

That structure turned out to double as a hallucination check. Once a claim is paired with its supporting data, Shoshan can hand both pieces, in a clean context, to a second model and ask a narrow question: is this claim supported by this data? "They tend to hallucinate a lot less because there's no noise," he observed of that verification step, adding that models asked a single, well-scoped question tend to be far more reliable than models buried in a long, historical context window.

This is a useful, concrete answer to a common question about context engineering AI agents: it appears to be less about stuffing more into the prompt and more about structuring what's already there so a second pass can verify it cheaply.

Trading RAG for a Knowledge Graph: An AI Agent Context Management Layer

The most counterintuitive move in Shoshan's setup involves search. Conventional wisdom over the last year has moved away from retrieval-augmented generation and toward letting agents explore data directly, the way they'd explore files in a coding harness. Shoshan's team seems to agree with that instinct, but takes it a step further: instead of dumping documents into an agent's context, or pointing it at a flat file system to explore, they built a knowledge graph of entities (services, accounts, exceptions, Slack messages) and their relationships, then let the agent walk it much like it would explore an "LLM wiki" on disk.

The graph isn't used as a traditional RAG index. It's a substrate for exploration: exact search or semantic search to find an entry point, then relationship-walking tools to follow connections outward. Building it, Shoshan said, was expensive largely because of data quality work, not model calls; cleaning noisy sources down to roughly a million usable entries, from what would otherwise have been many millions, took him several weeks of largely manual review. The payoff, he suggested, has been consistency: agents reliably find the pull request behind an exception, or the log line behind an incident, because the connections are already indexed rather than discovered fresh each run.

Adoption Is a Culture Problem, Not a Tooling Problem

Perhaps the most transferable lesson from the conversation has nothing to do with models at all. Cyera's platform now runs around 30 agents built by roughly as many engineers, but Shoshan's approach to getting there leaned less on mandates and more on ownership. Anyone who wanted to build an agent could fork the shared platform, give it a name and a personality, and make it theirs. "It really helps adoption because it was no longer, I'm adding a bit of code to a lead agent. It's my agent," he said.

That small psychological shift, from contributing to shared infrastructure to owning a named thing, appears to have done more for adoption than any top-down policy. Shoshan describes his approach as "all carrots and no stick": lower the barrier to entry, make the guardrails invisible, and let people bushwhack a little off the paved road when they want to.

For teams thinking about how to roll out agent platforms internally, that's arguably the more durable insight: the context engineering solves reliability, but the culture work is what gets anyone to actually use it.