Ember

Request a diagnosis

We’ll reply within one working day.

Or write to hello@emberhub.dev. We only use this to reply to you.

Blog

Guardrails do not make a stale fact true

A fair look at what agent platforms, enterprise search and semantic layers solve, and what a deployment still has to prove.

An authorized action can still be wrong

Suppose an assistant is allowed to draft a renewal offer, can read the customer's CRM record, and must obtain approval before sending. Those are useful controls. But if it uses an outdated price and the reviewer never sees the newer agreement, every control can function as designed while the offer remains incorrect.

That is not evidence that guardrails are useless. It is evidence that action governance and fact resolution are different jobs. One asks whether an action is permitted. The other asks whether the facts supporting it are fit for this decision.

It is tempting to describe the agent market as a collection of unguarded tools. The documentation does not support that blanket claim. The more useful comparison is which layer each system governs, and what evidence a buyer should demand for the remaining layer.

LangGraph provides a place to stop; the application must know why

LangGraph's interrupts pause execution, persist graph state and wait for external input before resuming. Its documentation explicitly supports human-in-the-loop patterns. [3] That is a building block for resolving uncertainty, not proof that a particular workflow detects uncertainty correctly.

A team can build cross-source reconciliation with those primitives. It still has to implement entity matching, contradiction detection, owner routing and rules for when a fact expires. The buying question is not 'Can it ask a human?' It is 'Which conflicts cause it to ask, what evidence does that person see, and can every dependent action use the corrected answer?'

Glean documents permissions and runtime controls

Glean's security documentation describes source-permission mirroring and permission-aware answers, agents and MCP results. It also describes write-action confirmations in interactive web sessions, with different behavior for other surfaces and background triggers. Its Protect+ agent access policies can evaluate tool inputs before execution and outputs after execution. [4, 5] Calling that 'no guardrails' would be inaccurate.

Those controls address access, egress and action safety. A permission to read two conflicting documents does not itself establish which document governs a contract. The reviewed pages do not establish a packaged, cross-system workflow that routes an unresolved commercial fact to its accountable owner and persists the answer for reuse. That is a limit of the evidence reviewed, not proof that Glean cannot support such a workflow.

Agentforce includes grounding; grounding needs a business rule

Salesforce documents a Trust Layer with grounding, toxicity detection, audit trails and other protections. Its Agentforce grounding material describes actions built on Apex, Flow, prompt templates and MuleSoft APIs, plus Data 360 and data libraries for connecting and retrieving data. [6, 7] It is not fair to describe this as an agent platform indifferent to data.

These mechanisms can be part of a resolution system. The open implementation question is how a deployment handles competing, legitimately accessible facts: which source wins in which context, what happens when the rule does not apply, and how a human answer changes future behavior. Connectivity and a cited response do not answer those questions on their own.

dbt resolves a real part of the semantic problem

The dbt Semantic Layer centralizes metric definitions, uses MetricFlow to generate queries, and exposes metrics and dimensions through APIs and integrations. [8] That directly addresses a common failure mode: different tools calculating the same named metric differently. dbt's own writing about agents emphasizes semantic ambiguity and structured context. [9]

A governed revenue definition is valuable. An unwritten exception to one customer's payment terms is a different object. It may need someone to confirm what was agreed before a model or metric can represent it. A semantic layer and an operational fact-resolution loop can therefore complement each other.

Buy the evidence, not the category label

Ask any vendor or internal team to demonstrate one realistic disagreement: an outdated structured record, a newer conditional email, and an action whose outcome depends on which one is authoritative. Can the system preserve the conflict, stop the affected action, ask the right person, record a scoped answer, and revoke that answer when the evidence changes?

The gap is not that every competitor ignores guardrails. The gap is that guardrails, retrieval and metric consistency do not, by themselves, establish the authority of an unresolved operational fact. Ember's stated focus is the loop that gets that fact answered. [2] Whether any product delivers it should be tested, not assumed.

Sources

[2] Ember: public product description

[3] LangGraph: Interrupts

[4] Glean: Core security principles

[5] Glean: Agent access policies

[6] Salesforce: Trust Layer

[7] Salesforce: Grounding agents with data

[8] dbt: Semantic Layer FAQs

[9] dbt: Why metric definitions matter for reliable AI agents