Build a Financial Workflow With Skills, Data and Codex

Stefano Fabbri and Oliver Steffmann work with financial institutions on applying AI. They introduce a hands-on workshop around a wealth-management use case: combining financial data, an AI model and useful outputs for an advisor’s day-to-day work.

The team helps customers move models into production for operations, agents and engineering productivity. Steffmann says he has a financial-services background and approaches the session as a builder as well as a product user.

The workshop has two parts: first, use ChatGPT Work for financial tasks; then use Codex to customize a workflow. Participants receive access to a dedicated workspace and work through exercises, with time reserved for questions.

Fabbri distinguishes ChatGPT, ChatGPT Work for knowledge work and agent workflows, and Codex for engineering-oriented tasks. He describes the financial-services offering as a product configured for financial work rather than a separate underlying model.

The presenters identify three components: financial data from built-in and connected providers, guidance for financial tasks, and artifacts such as spreadsheets and presentations. They also highlight source annotations and verification as part of presenting the result.

The built-in data they describe includes filings, market data, news, private-company profiles and earnings-call transcripts from providers including LSEG, PitchBook and Daloopa. They note that market data can be delayed, and that access depends on the product and data arrangements.

The team says the data is prepared with context so models can retrieve and interpret it more easily. Steffmann contrasts this with the work of collecting filings, updating them and building a scalable context layer independently.

A finance plugin combines reusable skills and connections to tools. The team says it worked with financial institutions on investment-banking and equity-research workflows, giving users a starting point that can be adapted to their own methods.

Fabbri suggests treating a provided skill as a baseline: try the workflow, identify what is missing and customize it for the organization. He mentions research, valuation, earnings analysis and presentation preparation as examples of financial work.

The exercise centers on a wealth advisor who notices a portfolio change, investigates performance and attribution, prepares an explanation and creates a client presentation. The purpose is to reduce preparation time so the advisor can spend more time with the client.

Participants can explore portfolio questions, research, charts, an advisor brief and a client deck. The workshop supplies example materials; users can adapt the exercises to different team workflows rather than assume every advisor works the same way.

For the builder portion, Steffmann asks how an organization can add its own data and customize the workflow. One option is a separate application using an API and a web interface. The other is to extend a surface the organization already uses.

A skill captures reusable instructions. When a workflow needs tools or access to data, a plugin can package those capabilities; a plugin extension can add an interface suited to the task. The workshop has participants explore each layer.

An audience member asks whether the finance product’s quality comes from instructions and tools or a different model. The presenters later explain that the work includes preparing data and context for retrieval, rather than simply attaching raw files to a model.

The workshop website divides the exercise between the user-facing finance workflow and building with Codex. Participants can start with the parts most relevant to them, then add a skill, a plugin, a data connection or an interface extension.

Steffmann describes an extension as a way to customize the surrounding interface for a workflow, such as showing a specialized view when a particular type of work or file appears. The plugin can include skills, tool configuration and an MCP connection.

The presenters distinguish the available surfaces at the time of the workshop. They say ChatGPT for financial services was in the ChatGPT Work web interface, while extension capabilities differed on desktop; the built-in financial data was not directly available through the Codex CLI.

Asked what sits beyond the model, Fabbri describes a financial-data context layer. It explains what different fields and documents mean, helping the model find relevant information and avoid simple misunderstandings—for example, confusing a price with a return.

The presenters say the skills also contain knowledge developed with financial partners. Steffmann adds that building a comparable context layer at scale entails collecting and updating data, as well as serving it efficiently.

When asked about access to the underlying data structures, Fabbri says they are not exposed in this product. He describes working with each provider to prepare data and tool calls suited to that dataset, rather than simply embedding every filing.

In the demonstration, a prompt selects the financial-services plugin, and the interface shows the data and tool calls used. The presenters describe the output as a combination of data access, task context and presentation choices such as tables or charts.

Built-in data is not enough for every firm. Fabbri suggests adding a custom plugin that connects internal tools and datasets and supplies firm-specific logic, while keeping the existing finance workflow as a starting point.

Steffmann says direct programmatic access to the built-in market data would be useful, but notes that licensing matters. A firm can instead build a connection to its own authorized sources and expose those through its workflow.

Fabbri says customers have been focused on token cost and efficiency. For new research or a new codebase, he sees a use for the strongest model. For repeatable work, detailed task context and a suitable skill may allow a less expensive model to meet the quality bar.

In a multi-agent setup, he suggests that the coordinating agent may need more capability than every individual worker. He emphasizes testing the actual use case: the right choice depends on measured performance, not simply on choosing the largest model.

Steffmann describes using a more capable model for the initial workshop website and a faster model for subsequent adjustments. His advice is to reassess capability, effort and price as models change, instead of assuming one setting fits every task.

Moving to the builder architecture, Steffmann shows a local Codex project, a local MCP connection, a hosted interaction surface and a firm’s internal systems. The developer can prototype a connection to a portfolio or client database, then decide how to package and deploy it.

The presenters describe a plugin creator for the managed web surface and a separate desktop route. An enterprise can distribute approved plugins through its existing deployment and access-control processes, rather than asking every user to assemble the workflow independently.

They say the built-in financial-services data remains on the web surface in this example. A firm-specific plugin can connect a separate database or service, with authentication and permissions appropriate to the organization.

Sandbox and enterprise policies are presented as layers around that deployment. Fabbri says administrators commonly need to decide which employees can use which plugins and access which data before making a workflow available.

Does a plugin require a server? The answer depends on what it does. A skill may be a set of reusable instructions, while an integration that connects to external systems can require code, a tool endpoint and authentication.

Steffmann explains that a plugin can package skills, MCP connections and optional UI components. An extension can expose an application entry point or a specialized view inside the working surface, so an advisor can access relevant context without switching among several sites.

For heavier workloads, Steffmann distinguishes model speed from the local computation needed to run tools and code. He discusses moving resource-intensive work, such as a large security scan, to a remote environment when local compute is the constraint.

Fabbri recommends sharing reusable skills and reference artifacts across teams. A plugin might include previous presentations, spreadsheets or research as examples, giving the model a concrete format to follow for a new client deliverable.

He says a team can correct recurring formatting or content problems in the skill, then test the next output. The goal is to preserve a reusable method while allowing a person to revise the final artifact.

Steffmann warns that teams can also create too many overlapping skills. Consolidating common capabilities, such as portfolio analysis, makes them easier to share and maintain. Both speakers say teams should retest behavior as models change.

Fabbri describes an earlier financial deep-research application built with the API. A planner divided a question into subquestions, independent agents investigated them, and a critique step compared the findings and sent contradictions back for further work.

A teammate explains recreating that workflow as a plugin. The reason was to bring the research into the interface where users were already working and reuse capabilities such as subagents and tool connections, while letting users adapt sources and quality gates.

Steffmann says the underlying Codex harness is open source and describes using an SDK when a team wants to take a prototype toward a server-side application. The team presents desktop and hosted deployment as choices that depend on the workflow.

Fabbri distinguishes the open-source engine from the proprietary first-party application. He says model training and the harness are designed to work together, and describes subagents and context compaction as useful for long-running tasks.

As an example, Fabbri describes asking Codex to reproduce code and numerical results from a quantitative-finance paper. He says the task ran for hours and credits context compaction with helping the system retain enough information during the work.

The speakers discuss bringing builder-created plugins to nontechnical colleagues through managed distribution. They describe this as a way to adapt to new data sources or analytical tasks within an organization’s existing environment.

Asked about other industries, the team mentions healthcare and cybersecurity. Steffmann notes that established companies often have fragmented data and suggests connecting useful sources incrementally while a broader data architecture is modernized.

An audience question turns to sandboxing. Steffmann says enterprise network and endpoint controls still matter, and describes administrator-managed policies for local files, network destinations and access to plugins. The team says permissions and approval settings are central to enterprise deployment.

In the closing questions, Fabbri argues that production agents need evaluations that reveal where they succeed and fail. A weak result may come from the workflow, instructions or tools as well as the model, so the team needs evidence before deciding what to change.

He says building evaluations is difficult partly because domain experts hold the business knowledge while engineers build the test system. His recommendation is to start with simple checks, then add complexity; for model-based evaluation he suggests breaking broad ratings into clearer yes-or-no questions.

For research tasks, he describes goal mode as specifying a target—ideally a measurable one—then letting an agent iterate on hypotheses. He gives prompt optimization against an evaluation set as a simple example and describes using subagents for independent investigations.

An audience member asks whether plugins can write back to systems of record. A team member describes using tools to persist results locally or to connect to a remote service, with appropriate authorization. In one proxy-voting example, the production record lived in an external application database.

Fabbri adds that regulated workflows need logs showing the sources and logic behind decisions, not just the final artifact. The team closes by inviting feedback from organizations implementing these workflows at scale.