Evidence at a glance
Capability Is Not Decision Authority
At AI Engineer New York in October 2026, Joseph Kim, who leads financial services at OpenAI, Two Sigma architecture executive John Feminella, and speakers from Anthropic and Bloomberg all addressed the same challenge: giving financial agents useful capabilities without letting them cross safety boundaries. OpenAI described a “threshold of usefulness”: delegation becomes worthwhile when a model is reliable enough to save users time.
The important shift is not that financial firms are ready to hand trading over to models. It is that “can the agent do it?” is being separated into three questions: what can run automatically, what needs human review, and what should remain a recommendation. Kim predicted that agents might contribute to investment idea generation and trading by 2027, but the conference account offered no evaluation data to support that forecast. It is a prediction, not evidence that today’s products can trade autonomously.
Financial Workflows Need to Explain Their Numbers
In finance, a plausible answer is not enough. Analysts need to know where a figure came from and the context in which it was produced so they can check the calculation, assess whether it is current, and decide whether to use it. Kim therefore treated traceability as part of turning model capability into a usable product, not as documentation bolted on afterward.
That requirement shapes the workflow. If a system returns only a conclusion, users must reconstruct its sources and reasoning themselves, potentially erasing the time saved by automation. OpenAI’s financial-services product is described in terms of research, financial modeling, and client materials; those use cases do not establish that it can make investment recommendations or decisions on a user’s behalf. For engineering teams, the deliverable is not just a generated answer, but a way to inspect its basis, understand its context, and retain control at consequential steps.
Route by Risk Instead of Asking for Approval Every Time
Two Sigma frames controls as composable guardrails rather than blanket limits on model capability. Feminella warned that requiring approval for every action is not automatically safer: repeated reviews can create “approval fatigue,” leaving people less attentive to each request. The design question is therefore not simply whether a person is in the loop, but when they enter the process and whether the request merits their attention.
The conference account describes two ways to route work. Deterministic rules suit cases with clear boundaries, while an auto-mode classifier can direct ambiguous or consequential requests to a person. Two Sigma said it had implemented five controls, but the account explains only the classifier and deterministic rules; the full list and operating details were not provided. The principle is clearer than the implementation: avoid interrupting people for routine cases and reserve human attention for decisions more likely to affect the outcome.
Keep a Boundary Between Recommending and Acting
Anthropic described trust in financial workflows in three layers: establish identity and permissions, constrain actions through sandboxing and approval, and check whether those controls remain valid when the environment or relevant variables change. The point is not simply to ask users to “trust the model,” but to specify what it can do, what it can access, and when changed conditions require renewed scrutiny.
A transaction-discrepancy investigation provides a concrete example: an agent may recommend an order change without directly modifying order data. Separating analysis from execution lets the model help investigate a problem without granting it authority over trading records. Bloomberg’s presentation added deterministic controls outside the model, including restricting identities and credentials, limiting tool calls and outbound traffic, keeping audit records, and setting budgets and a kill switch. The account also describes an agent misreading a malicious instruction in a market-platform comment as a restocking request, but does not say whether the incident caused any loss.
Measure the Controls Before Expanding Automation
The practical lesson for technical leaders is not to copy one firm’s list of safeguards. It is to break a workflow into actions with different risk levels and assign authority to each: which steps may run automatically, which may only produce recommendations, and which require human approval. High-impact operations such as modifying an order are natural candidates for a “recommend, do not execute” boundary, backed by traceable records and a way to stop the system. That creates room to delegate more work without requiring a person to watch every step.
The available material provides no rates for erroneous actions, approval catches, prompt-injection defenses, or post-deployment losses. Nor does it define a common evaluation method for a “threshold of usefulness.” Without those measurements, it is impossible to tell how much a control reduces risk in real operations or to establish that models are broadly ready to take over financial decisions. A sound engineering judgment is to define observable risk measures and explicit limits on authority before expanding automatic execution. Greater model reliability cannot substitute for validating the workflow.