Build Your Own Finance Agent Inside ChatGPT - Stefano Fabbri & Oliver Steffmann, OpenAI

A client’s portfolio has moved out of balance. Before the meeting, the advisor needs to answer three questions. What changed? Which holdings contributed to the gain or loss? What adjustments should they discuss with the client? A chart of market prices can help with the first question, but it says little about this particular client until the advisor connects those prices to what the client holds.

Stefano Fabbri and Oliver Steffmann of OpenAI’s applied AI team framed their workshop around that preparation. Participants received a package of sample client data and could work on portfolio analysis, research, or charts separately. The intended deliverables were a profit-and-loss statement or portfolio attribution, followed by a presentation explaining the change and possible adjustments. The advisor would use the deck to conduct the conversation.

That sequence gives an engineer a practical way to decide what to build. Try the analysis with the supplied holdings and the finance tools first. See what an advisor can already produce, where they need to supply firm-specific knowledge, and where they have to leave the workspace to retrieve a number. A repeated explanation and a missing client record both slow down meeting preparation, but they call for different engineering work.

The enterprise finance product described in the workshop included SEC filings, earnings transcripts, news, private-company profiles, and market data, with providers including LSEG, PitchBook, and Daloopa. Fabbri estimated the market data delay at about 15 minutes. For an advisor explaining a portfolio move, the time a price represents matters just as much as the ability to retrieve it.

Asked whether special embeddings accounted for the product’s handling of filings, Fabbri pointed to preprocessing. The team worked with providers on how to represent each dataset and what context to supply when the model retrieved it. For a 10-K or 10-Q, that included an explanation of what the filing contains. For market data, it included distinctions such as price versus return. A tool can retrieve the intended security and still lead the analysis astray if the model interprets the series incorrectly.

Fabbri suggested thinking of retrieval as a tool call specialized for a particular dataset. In the demonstration, the interface exposed the finance plugin’s tool calls, while the underlying data representation stayed internal to the product. The plugin also supplied guidance on validating data, noting its origin, and presenting results. That approach carries over to a firm’s own portfolio tools. Part of connecting a source is deciding what an analyst needs to know to interpret the value it returns.

The speakers used a skill to capture a procedure in reusable Markdown. Portfolio analysis is a good unit because several advisors can share the method even when their meeting workflows differ. A skill can also refer to files. The team suggested including historical research, spreadsheets, or presentations and directing the model to put a fresh analysis into the established format. An advisor can then point to a specific discrepancy in the output and amend the shared instruction for the next run.

A live portfolio database introduces a different requirement. Steffmann described prototyping a local Model Context Protocol (MCP) server in Codex to expose tools for querying holdings or customer records. A plugin packages skills with the tool configuration and, where needed, code and interface components. The engineer must decide whether the connection authenticates system to system or acts on behalf of the signed-in user. Installing the plugin addresses distribution. The internal service still has to enforce access to its records.

The distinction also helps teams decide when to stop building. Steffmann had seen customers accumulate so many slightly different skills that colleagues struggled to find and maintain them. He advised keeping portfolio analysis or trading analysis as a shared capability. If two advisors use the same attribution method but present their findings differently, a shared analysis skill and their respective example decks preserve the distinction without duplicating the entire procedure.

At the time of the workshop, users accessed the integrated financial data through the ChatGPT web product. A developer could install a local MCP server in Codex, but access to the web product’s market data did not carry over to a CLI pipeline. The speakers also flagged data-provider licensing as a consideration for API access. For an engineer planning a scheduled job, the consequential question is whether the environment that will execute it can reach the required source.

A plugin extension addressed a narrower problem on desktop. Steffmann described an advisor preparing for a meeting who wants to see a particular metric from the firm’s system. An extension could display a client-specific view within the conversation, add navigation, or respond when a particular file type appeared. At the workshop, those interface extensions were desktop-only. An advisor who simply needs a table or a finished PowerPoint has a different requirement from one who needs to inspect an internal metric repeatedly while working.

Building within an approved workspace let the team use existing administration and plugin distribution. Steffmann also described a limit he had encountered with local execution. A large repository security scan could tie up his laptop, and faster model output did little for code that still had to run on that machine. For work that outgrows a workstation, he described using the Codex SDK to run it on a server. The choice of user interface and the choice of where to spend compute can be made separately.

The team’s equity-research example shows when a workflow merits orchestration beyond a single skill. In an earlier API application, a planner broke a research question into subquestions and assigned each to an independent agent. A critic collected the findings, checked whether they conflicted, and dispatched another agent to investigate a discrepancy. An unresolved disagreement supplied a concrete reason to spend more compute. The critic also checked whether the combined report covered the original questions.

The team later recreated that workflow as a Codex plugin. The original application mixed fixed processing steps with model decisions. In the plugin, Codex handled subagents and could select tools as the investigation developed. Analysts could see what the subagents were researching, specify which sources to use, and change the checks applied to the report. Those were practical reasons to move the work into the analyst’s workspace even though a standalone application already existed.

The speakers distinguished this open-ended research from a recurring report whose inputs and expected format are familiar. They had found that a more capable model helped with planning or unfamiliar work, while a cheaper model could handle some delegated tasks given a well-specified skill. That observation matters when a report runs across a client base. Whether the substitution pays off depends on how well the cheaper model performs that particular task and how often someone has to correct its output.

A desktop extension can execute code on an employee’s machine. Steffmann described administrator-managed TOML policies that restrict workspace access, network destinations, and which plugins particular teams can use. His examples included allowing work inside a project while keeping sensitive folders out of reach and restricting the URLs a tool could contact. Those controls complement enterprise network and endpoint controls. The team operating the tool remains responsible for protecting the service behind it.

For output quality, Fabbri identified a different deployment bottleneck. Engineers can build an evaluation dataset, but subject-matter experts know which mistakes would make a report unusable. He recommended starting with simple checks and inspecting their results individually. In the advisor workflow, using the intended financial series, documenting its source, and following the client’s presentation format are distinct requirements. An aggregate score gives the engineer little direction about which failure to investigate.

Fabbri advised introducing a model as judge only after the team understands its simpler tests. When model judgment is useful, he favored narrowly framed yes-or-no questions over a one-to-five rating. A failed check then gives the team something specific to trace through the tool response, the instructions, and the model’s handling of them. The same checks can be rerun when switching models or revising a shared skill.

An audience question about writing data back exposed one last architecture decision. Codex can use the local project filesystem to retain tool output across a long task. That can serve someone developing an analysis at their desk. When another application needs the result, the workflow needs an explicit destination and a tool with permission to write there.

The team described a proxy-voting workflow in which Codex was the operator’s workspace and an external application server owned the record. A tool connected through the extension wrote the report, findings, date, and sources to the database that powered the production application. The speakers said they also retained standardized logs for audit-sensitive work so a reviewer could trace actions and decisions to the data and logic behind them. For a portfolio review, the same design question is worth settling before rollout. The client deck serves the meeting. The firm must also decide where an authorized reviewer can recover the evidence behind it.