Noyan Tokgozoglu: How Optiver Builds an AI Platform for Fast, Measurable Decisions

I am Noyan Tokgozoglu, head of AI engineering at Optiver. We are a market maker: we facilitate trading with our own money, using data and models to make decisions. The firm makes more than 10 million trades and prices more than one million instruments a day, processing petabytes of data across a global operation.

In a conventional technology business, a product change may take weeks to generate engagement data and quarters to show its revenue effects. At Optiver, a change for traders or quantitative researchers can show an effect on profit and loss within hours, although some instruments and decisions have longer horizons.

Fast feedback cuts both ways. A missed market opportunity can be costly, so we need to act quickly and measure effectively. That environment shaped the AI platform we built: speed matters, but so does knowing whether a new model or technique adds value.

Our platform principles include moving fast, modularity and measurement at every layer. Models, tools and agent patterns change rapidly, so we need to benchmark useful developments and bring them in without rebuilding the entire stack. External benchmarks are not enough because our internal data and use cases have different distributions.

Traders are capable and independent, so the platform should be self-service with sensible defaults. Our AI engineers also sit with trading teams, learn their workflows and help apply AI directly. The lessons from that forward-deployed work return to the shared platform.

Safety matters because an agent acting incorrectly in our stack can have serious consequences. Everyone in the company uses AI in some form. Our infrastructure and GPUs are on premises; third-party model inference is an exception, covered by arrangements such as zero-data-retention agreements.

The platform includes third-party and self-hosted models behind an inference gateway. The gateway routes requests, measures spending and supports budgets and provider substitution. If one provider is unavailable, another can help maintain service, which matters when downtime has a direct business cost.

Above that are agents with registered skills, plugins and tools, plus team knowledge and memory. An agent gateway provides a shared layer for agents and people to communicate and orchestrate work with identity management. Different teams can bring their own context into this system.

The user surface matters as much as the platform. We built a web interface for sessions, an agent workbench where teams can configure and share profiles, and a personal assistant available across the company. A platform has little value if users cannot or do not want to use it.

One goal is to make a newly public frontier model available to production workflows the same day—if it proves useful. We benchmark against internal golden sets gathered with trading teams, then share the results and recommendations so users can judge the value for their own work.

A model release also requires gateway support, interfaces, cost management and sometimes harness updates. Launching it is not the end: a global firm needs round-the-clock support, regional rotations and communication about what was tested, how it performs and how to use it.

We want optionality across models and harnesses, including on-premises workloads in isolated environments. Third-party providers and self-hosted models go through the inference gateway. We log model interactions and feed them into our evaluation system.

A meta-harness layer lets teams configure experiences across different harnesses and connect to their knowledge bases. We derive additional knowledge from traces over time. Teams can deploy and manage agents on the platform or access them through interfaces such as the web portal and IDE.

AI usage and spending rose sharply, particularly around major model releases. The chart I show is illustrative and has no spending figures. We believe additional use can create value, but we want to spend wisely and improve the return from the tokens we buy.

One problem was excessive default context. In a fresh session, some setups loaded roughly 200,000 tokens or more before the user had done anything, as teams accumulated MCP tools and background information. Pure self-service without attention to defaults can become expensive.

We added MCP tool search, offered agents command-line wrappers around groups of tools and examined cache invalidation and lifetime. We also worked with teams to optimize harnesses, including moving material from a massive system prompt into a knowledge base when appropriate.

Making spend visible helped too. Teams can set their own alerts and limits, and many choose reasonable boundaries when given that information and agency. We also use on-premises open models where they are a good value for a particular task, without assuming they fit every use case.

We are exploring model routing and dividing work between a more capable model that plans and smaller models that implement parts of a task. Effective knowledge retrieval can also reduce unnecessary context. The goal is not simply to use fewer tokens, but to obtain more value for the investment.

To meet users where they were, we looked at the bespoke harness setups and improvised web interfaces people were already making. We built a shared web portal for sessions, chat and artifacts that fits our infrastructure and can be iterated at our own pace.

Traders now contribute code for their own workflows, and the portal has gained features such as collaborative document editing. We are moving toward shared rooms where people can work with their own agents and other deployed agents, with a Slack client for access on the move.

In questions, I said our knowledge-base solution is still imperfect. Markdown and vector search each have strengths and limitations, so we use a hybrid approach and want to explore options such as graph databases. Memory and retrieval remain areas for further work.

Why build instead of relying entirely on vendor solutions? Our on-premises requirements made some offerings difficult to use, and deep dependence on one provider can leave us moving at that provider’s pace. I do not claim our approach fits everyone; our particular circumstances and engineering capacity make it viable for us.

Evaluation has another hard problem: a tool’s world may have changed since the original agent run. A trading backtest database can often be queried at a point in time; recreating the earlier state of Slack or another service may be much harder.

We try to estimate how confidently each tool call can be replayed at the original point in time and use a proxy around MCP tools when rerunning evaluations. The result remains imperfect; reconstructing the world state is an open problem rather than something we have fully solved.

When teams combine agents, simply taking the union of all their capabilities can create complexity and technical debt. For small changes we can version an agent, but for broader work we increasingly prefer agents scoped to measurable tasks that communicate through a shared gateway.

That becomes an orchestration problem, but it preserves clearer lifecycle management and evaluation. A single bloated agent can improve in one capability while worsening in another, making the overall system difficult to tune.