Goldman Sachs' "AI in Action": How Top Investment Banks Explore the Productization of Agents

Goldman Sachs' "AI in Action": How Top Investment Banks Explore the Productization of Agents

The biggest pitfall for companies working on AI is mistaking a stunning demonstration for proof that the product is already usable.

Chris Churchman, head of Goldman Sachs' digital platform Marquee and co-chair of the Global Banking and Markets AI Working Group, recently offered a more draconian standard in a podcast: AI demos only showcase "the best performance"; however, once an institutional product is launched, the worst output will be scrutinized by the market and clients.

This statement hits the real bottleneck in the transition of enterprise AI from Proof-of-Concept (PoC) to production. Cutting-edge models, when combined with enterprise data, can easily generate a fluent, complete, and seemingly professional answer; however, in high-risk scenarios such as finance, being "generally correct" is meaningless.

Whether the facts are accurate, whether the calculations can be verified, whether the conclusions exceed the authorized limits, and whether errors can be stopped in a timely manner determine whether an enterprise can allow the system to enter the real process.

This interview outlines four productization boundaries: do not use demos to replace acceptance testing; do not bet on temporary defects in the model; redo the workflow; and do not outsource human judgment.

Goldman Sachs' "AI Experiment"

Marquee is Goldman Sachs' digital platform for institutional and corporate clients, designed to help them make decisions and navigate their investment processes amidst high uncertainty.

The platform aggregates millions of research articles, trading floor commentary, pre-trade analysis, and content from dozens of data providers. Churchman likens the Market View to "Pinterest for the capital markets": each component is created by domain experts, and the platform already has millions of analytics components.

Marquee AI, currently used only within Goldman Sachs, is attempting to transform these disparate capabilities into a unified entry point.

After a user submits a question, the system will break down the research topic, look for relevant research, trading floor opinions and analysis components, write and run Python calculations when necessary, and then return a conclusion supported by evidence.

Its goal is not to "create another chatbot," but to enable the capabilities of complex mechanisms to be mobilized by natural language.

The financial industry cannot accept "almost right" AI.

In the interview, Churchman mentioned that even if a model is 90% correct in its assumptions, it may still have no practical value. This is because users don't know where the errors are hidden in the 10%, and ultimately still need to verify all the facts. AI may seem to save writing time, but it shifts the cost to verifying each statement one by one.

While ordinary users can tolerate a single inaccurate recommendation, institutional products must rigorously address issues such as permission errors, expired data, source conflicts, tool call failures, and abnormal market conditions. Average accuracy rates cannot answer where the errors lie, the extent of their impact, or whether the system can be securely taken over.

Churchman used a vivid analogy: once facts and inferences enter the context window, they both go through the "sausage machine," and the model itself cannot distinguish which is the fact and which is the interpolation. It's not intentionally misleading; it simply doesn't know the difference between the two.

Therefore, Goldman Sachs' goal for Marquee AI is to make every important statement traceable to research materials, trading desk comments, or auditable calculations.

The "source" here does not mean attaching a few links at the end of the answer, but rather that the judgment corresponds one-to-one with specific evidence, and the calculation process can be reproduced.

For enterprises, when accepting agents, the test suite should not only include standard questions and normal processes, but also actively include situations such as expired documents, contradictory data, insufficient permissions, interface timeouts, duplicate submissions, and inability to answer.

It is necessary to record not only the accuracy of answers, but also the traceability of citations, the rate of human intervention, unauthorized or misoperation, failure recovery time, and the total cost of completing a qualified task.

The difference between a product and a demo lies precisely in these seemingly boring engineering tasks that are unlikely to become selling points at a product launch.

Don't bet on model flaws; build models that can't learn.

Churchman's second judgment was: Don't gamble with the improvement of model capabilities.

Churchman recounted that the early model only had about 4K token context, equivalent to about 3,000 English words. The developers had to slice and embed them into a vector database and study how to avoid the "loss in the middle" phenomenon.

Subsequently, the context window was upgraded to 128K, then to 1 million tokens, and long text retrieval was rapidly improved; function calls and MCP also absorbed a large number of tool connection scaffolding. The product barriers built around temporary defects are likely to depreciate rapidly after the next model version is released.

This does not mean that RAG, workflow orchestration, or agent frameworks are useless. The change is that they should not only be used to compensate for models' inability to "read long texts" or "operate tools," but should also be used to handle tasks that models cannot solve independently: determining which material is the authoritative version, when knowledge becomes outdated, what the current user can see, how different data are related, where the conclusions are based, and who approves the write operation.

Churchman summarizes these as institutional details that models cannot learn from massive amounts of public training, including enterprise-specific data, permission systems, data connection methods, and business authorization.

For B2B AI providers, this means that general generation, search, and tool invocation will become commoditized more and more quickly; the more lasting value will shift to enterprise context, system integration, access control, evaluation, and continuous operation.

Enterprises should follow the same principle when building their own systems. Instead of investing heavily in replicating common capabilities that are likely to be internalized by the model factory, they should prioritize building their own authoritative knowledge sources, business objects, interfaces, permission mappings, evaluation sets, and accountability systems.

Models will be upgraded, but organizational facts will not be automatically compiled, and organizational responsibilities will not grow out of the parameters.

Agents move into production; the next step is "licensing."

The interview also outlined a clear technological evolution path: from cue word engineering to context engineering, then to agent engineering that allows agents to check and correct their own work; next came environment engineering, and then “licensing engineering,” which has not yet become a common term.

Environmental engineering addresses where the agent operates: whether it can enter a secure environment, access the latest knowledge and correct tools, retain its real identity and permissions, and make every action observable, pauseable, and rollbackable.

Authorization projects address more complex issues: what agents are allowed to do, in whose name they act, based on whose authorization they act, and who bears responsibility if problems arise.

The more powerful the model, the less these issues can be addressed after deployment. Autonomy should not be simply understood as "the ability to execute more steps continuously," but rather as the system independently completing tasks within clearly defined boundaries and proactively stopping when those boundaries are reached.

For high-risk processes, a feasible structure is usually as follows: AI completes material identification, information verification, analysis or preliminary review; key decisions are confirmed by designated personnel; and the results are written back to the original business system and enter the existing audit chain.

This is also the real reason why many Proof-of-Concept (PoC) projects fail to scale. Demonstrations only need to prove that the model can do it, but the product also needs to prove that the organization dares to make it do it.

Instead of automating old processes, it's better to rethink the task.

Churchman divides the use of AI in enterprises into two approaches: automation and rethinking.

Automation identifies cognitive bottlenecks in the original process, such as reading, reviewing, and data entry, and replaces manual labor with AI to achieve the same results at a faster speed. It is easy to implement and can generate efficiency, but it may also solidify the redundancy in the historical process.

The rethinking starts with "what really needs to be accomplished," assuming that intelligence can be invoked at low cost and flexibly, and then redesigning the division of labor between humans and software. Churchman summarizes this shift as: in the past, users learned software; now, software learns users. Marquee AI doesn't empower users with more menus, but rather understands their research intentions and then organizes research, data, tools, and computation.

He also acknowledged that the native product form of AI has not yet emerged: the industry is like when television was first invented, still broadcasting radio programs on television, or like it was still in the command line stage, before it entered Windows and the mouse. Today's many products that are "chat boxes with old processes" may just be transitional forms.

Enterprises can use the same distinction to determine the value of an agent project. If AI merely generates a result, and employees still have to manually transfer it back to the original system, re-verify it, and initiate approval, it may just be adding another interface. A true closed loop should reduce cross-system handover, allowing the result to enter subsequent processes, while retaining necessary confirmation and rollback mechanisms.

The one thing that should never be outsourced is human judgment.

The most significant aspect of this interview is the concern about the decline of human capabilities.

Churchman argues that as technology increasingly replaces memory, navigation, and information retrieval, generative AI is beginning to take over argumentation and reasoning. If companies only pursue reducing manual steps, younger employees may skip the training needed to form professional judgments. Much institutional knowledge is not documented but passed down through mentorship and hands-on experience; over-automation could lead to a direct break in this knowledge chain.

He likened reasoning ability to physical fitness: just as people need to go to the gym because they sit in an office for 12 hours a day, the AI era also needs to build a "gym" for thinking. He hopes that ten years from now, Goldman Sachs' new recruits will be more like "fighter pilots," able to process large amounts of information and make judgments in uncertainty, rather than "bus drivers" who simply drive along predetermined routes. This is not about rejecting AI, but about requiring products to enhance human reasoning, rather than abandoning reasoning for people.

Therefore, good corporate AI should not hide the evidence upon which reasoning relies, but rather help people make better judgments: showcasing sources and calculations, clarifying facts, assumptions, and inferences, exposing conflicts and uncertainties, and leaving high-risk choices to those who are responsible. AI can expand human information bandwidth, but it should not deprive people of the ability to question outputs.

The real moat of enterprise AI

Goldman Sachs' experience ultimately points to the same conclusion: the moat for corporate AI is not to repackage a general model, but to build a working environment that the model cannot learn from the public world.

This includes authoritative data and its relationships, identity and permissions, task authorization, tool interfaces, anomaly upgrades, business acceptance, and organizational memory. Model upgrades consume a lot of temporary scaffolding, but they don't automatically answer for the enterprise: which facts can be used, who has the authority to take action, what results are acceptable, and when decisions must be handed back to the appropriate authority.

For suppliers, the next phase should not only demonstrate what the agent "can do," but also explain how to stop, investigate, and recover in the worst-case scenario. For enterprises, procurement should not begin with a feature list, but rather with real-world tasks, testing completion rates, traceability, human intervention, and unit costs under real-world permissions and abnormal conditions.

Demos demonstrate AI's capabilities, while products demonstrate an organization's ability to trust those capabilities. Moving from the former to the latter is where B2B AI applications truly begin to create value.

This article comes from the WeChat official account " AI Native Lab " , which continuously analyzes real-world AI implementation cases and shares enterprise AI practices and methodologies.

Risk Warning and DisclaimerInvesting involves risk; please exercise caution. This article does not constitute personal investment advice and does not take into account the specific investment objectives, financial situation, or needs of individual users. Users should consider whether any opinions, views, or conclusions in this article are suitable for their specific circumstances. Any investment decisions made based on this information are at your own risk.