Applying Regulation Best Interest (Reg BI) Checks to LangGraph Agent Recommendations at Runtime

What a runtime check has to answer

Reg BI sets a standard of conduct for broker-dealers and their associated natural persons when they recommend a securities transaction or investment strategy involving securities to a retail customer. The General Obligation is satisfied only if the broker-dealer complies with four component obligations: Disclosure, Care, Conflict of Interest, and Compliance.

Two features of the rule shape the engineering. First, whether a firm acted in the customer's best interest turns on an objective assessment of the facts and circumstances at the time the recommendation is made, not in hindsight. A check that runs before the recommendation is delivered matches that framing more closely than sampling transcripts afterward. Second, a recommendation is not always an explicit buy or sell. Where a firm agrees to provide specified account monitoring, the SEC's view is that buy, sell or hold recommendations arising from that agreement are subject to Reg BI, even when the hold recommendation is implicit. Triggers that match only on explicit buy or sell language will miss this case.

The obligations rest on the broker-dealer. Whether your firm is a broker-dealer or an investment adviser determines which standard applies, so confirm applicability with your compliance function before you scope any checks.

Translate each component into testable conditions

Start with a scoping check, then organize the four components as separate check groups. The conditions below are a design pattern. Your compliance function should derive the exact conditions from the full rule text and the firm's procedures, because not every sub-requirement can be evaluated on a single interaction.

• Scope trigger: Decides whether an output is a recommendation to a retail customer. Cover explicit recommendations, implicit hold recommendations under agreed monitoring, and recommendations produced by agent-selected tools.
• Disclosure group: Checks that the disclosure content your firm requires is present in the response before it is delivered.
• Care group: Checks that the basis for the recommendation is stated and that the customer context needed to support it was supplied to the agent.
• Conflict of Interest group: Flags outputs that touch products or incentives your firm has marked as conflicted, so the response can be handled under your conflict procedures.
• Compliance group: Checks that the interaction carries the references your supervisory process needs, such as the policy version applied and the route for review.

Define allow, redact, block and escalate per scenario

Decide the outcome for each scenario before you write code, and document it. A reasonable starting pattern is shown below, to be set by your compliance function.

Allow applies when the scope trigger does not fire, or when every check group passes. Redact applies when a segment can be removed and the remainder still stands as a complete, compliant response, for example a statement that goes beyond the supplied basis. Block applies when a required element is missing and cannot be repaired safely, such as a recommendation with no required disclosure. Escalate applies when a conflict flag is raised or when the check cannot reach a confident result, and the graph pauses for a named approver.

Two decisions deserve explicit documentation: what happens when a required disclosure is missing, and what happens when a conflict flag is raised. Leaving these implicit is how inconsistent behavior enters production. Add test cases for implicit hold recommendations and for tool-generated recommendations, so coverage does not depend on how the agent phrases its output.

In-graph logic, execution-path policy and the limits of both

You can write these checks as functions inside the graph. That works for a single application, but the logic then lives in application code, changes with each release, and is repeated wherever another team builds an agent. Enforcing policy in the execution path keeps the rules, their versions and the evidence format in one place, separate from the graph. The argument for this is a design rationale: it makes outcomes and records uniform across agents, and it avoids depending on every team to implement checks identically.

Trussed takes the second approach. It enforces policy in the execution path across models, agents, tools and MCP servers, with outcomes of allow, redact, block, rate limit or escalate for human approval, and produces audit-ready evidence from that enforcement. Its scope is individual interactions and tool calls. It does not govern business transactions across tasks and agents, and it does not trace end-to-end agentic workflows.

That scope defines the limit of any per-interaction check. A check sees the context it is given. Care judgments that depend on a customer's full profile, and the firm's supervisory procedures and Compliance Obligation, remain with the compliance function. Runtime enforcement supplies consistent decisions and evidence to that function. It does not guarantee compliance with Reg BI.