blablaablaaa @jaggerxtrm - Twitter Profile

Pinned Tweet

14 days ago

I have been actively using LLMs to help turn my ideas into real systems since Claude 3.5 Sonnet, the first model that made AI-assisted coding feel genuinely real to me. It was not that long ago, but considering how quickly models, tools and available resources are progressing, it already feels like another era. About a year and a half ago, after a particular event in my life, I decided to dedicate much more time to developing and applying what I had learned through years of trading, and to understanding how agents could improve that work. During a ten-day hospital stay, with an iPad and a keyboard, I wrote more than 100 pages of plans, architecture and documentation around what would eventually become Mercury. A second project emerged naturally from the same work: a system for autonomous and coordinated agents, now called xtrm. One of the things that bothered me from the beginning was the inevitable “You’re right…” that an agent gives you after it has already implemented the wrong thing. But what had actually failed? Was my request wrong? Was the context incomplete or badly structured? Had I failed to define the constraints? Or had the agent quietly taken its own direction, made assumptions and simply produced the wrong result? I also noticed that continuing the same conversation after a serious mistake often led to progressively worse results. The model started behaving as if it were under pressure, almost like an employee who had been reprimanded and was now more concerned with avoiding another negative reaction than with doing the work correctly. It would agree too quickly, overcorrect, become excessively cautious or optimize for approval rather than accuracy. Before becoming a full-time trader, I worked in management, so I recognized the pattern. A language model obviously does not feel fear, but the resulting failure mode was surprisingly similar. That observation became part of the reason xtrm exists. Agents need much more than longer prompts and more tokens. They need explicit context, boundaries, task contracts, evidence, review, deterministic validation, recovery paths and coordination. They also need a clear distinction between what is authoritative, what is an assumption and what still needs to be verified. Finance and markets exposed an even larger problem. There is an enormous amount of financial information available, but much of what is most visible, repeated and likely to appear in model training data is retail-level information. It is often oversimplified, copied endlessly from one source to another, detached from actual market structure and sometimes simply wrong. Much of it has very little value for a professional trader. This is particularly dangerous with language models because they are very good at producing fluent explanations. An answer can sound intelligent even when the framework underneath it is weak, the data are inappropriate or the reasoning is based on concepts that no serious practitioner would use in that way. That is why I spent those 100+ pages describing how information should be structured from the point of view of someone who actually trades, and who has developed a fairly sensitive bullshit detector over the years. How should an agent reason about fixed income, curves, spreads, central banks, liquidity, volatility, positioning, market structure and macroeconomic data? Which sources are canonical? Which transformations are valid? Which assumptions must always be explicit? Which calculations should never be delegated to free-form language generation? What should be handled by deterministic infrastructure, what should be validated, and what should be preserved so that the work can be inspected, reproduced and resumed later? A year and a half later, Mercury reflects an almost obsessive attention to those details. It is built on a substantial server, cloud and data stack, with high-quality quantitative and qualitative information, government and economic sources, market data, domain-specific transformations, quantitative tools, academic and canonical knowledge, industry-standard methods and validation from people who genuinely understand the mathematics involved. This matters because language models are not naturally designed to analyze raw time-series data. They are not designed to look at an image of a chart and somehow produce analysis with a real and durable edge. There are now countless products that connect to TradingView, capture candles or chart images, send them to a model and return something that looks like analysis. That is not what Mercury is. A candlestick chart is already a compressed visual rendering of underlying data. Asking a language model to infer sophisticated market structure from the pixels means discarding precision before the reasoning has even started. The model does not know what relevant information is missing, which transformations produced the chart, what happened elsewhere on the curve, which macro events occurred, how volatility changed, whether liquidity was abnormal or whether the apparent pattern has any statistical significance. LLMs are far better at connecting dots than they are at manufacturing reliable dots from raw numerical information. They can synthesize, compare, contextualize and identify relationships extremely well, but only when the information they receive has already been structured correctly. Mercury starts one layer earlier. The infrastructure retrieves, transforms, calculates and packages the information. The agent works with structured outputs, domain-specific methods and reliable tools instead of guessing from pixels. The human can then inspect the same evidence, verify what the agent saw, review the calculations and continue the work through a high-quality visual and functional platform. Mercury is agent-first, but it is not human-absent. The principle is that the human should be able to see what the agent sees: not only the final answer, but also the data, assumptions, calculations, sources, intermediate artifacts and analytical path behind it. The same principle applies to quantitative research. LLMs still perform poorly when they are expected to carry out unconstrained mathematics entirely through language. Mathematics is too broad and often requires forms of abstraction, rigor, creativity and critical reasoning that models do not possess consistently yet. But an LLM does not need to replace a mathematical system. It needs access to one. With a solid quantitative infrastructure, an agent can help someone express an idea, translate it into formal assumptions, select appropriate methods, build a statistical model, test it, identify its weaknesses and determine whether it deserves further development. This allows someone who is not necessarily a mathematician, programmer or quant developer to apply an idea without pretending that statistical validity can simply be generated through language. The infrastructure remains responsible for calculation, validation and reproducibility. The model helps coordinate the reasoning. I believe we are moving toward a period in which people will increasingly interact with the internet, software and data through agents rather than directly through websites and dashboards. The agent will search, retrieve, calculate, compare, organize and prepare information. The user will inspect, direct, question and decide. Most financial platforms were designed for a human clicking through screens. Mercury is being designed for a world in which the primary consumer of the infrastructure may be an agent, while the human still retains full visibility and control. That means structured access through MCP, APIs and CLI tools. It means avoiding unnecessary token usage, returning compact but information-dense results, preserving sessions and artifacts, and allowing research to be resumed instead of disappearing inside an old conversation. It also means giving agents access to financial knowledge that is more precise than the generic material contained in their training data, and eventually allowing users to preserve their own sessions, reports, charts, models and research artifacts in a space that remains accessible both to them and to their agents. Some of you have heard me mention Mercury for several months while the details have remained intentionally limited. At the moment, it is available only to a small group of people. Soon, we will open access to a public beta for a limited period. There is already an application form on our website, but it will shortly be replaced by a more detailed version explaining the product, the current scope of the beta and the type of users we are looking for. One thing should be clear: there are dozens of open-source and commercial financial dashboards, and most of them do roughly the same thing. They show familiar data to a human through slightly different charts, tables and interfaces. There is nothing inherently wrong with dashboards, but Mercury was not created to become another one. It was built to expand what a trader can know, connect, test and investigate through agents. It was built to give those agents better data, better tools, better domain knowledge and better constraints, and to help traders search for genuine edge with far greater depth and rigor. Not AI commentary over a candlestick chart. Not another collection of generic indicators. Not another interface showing the same information everyone already has. Financial intelligence infrastructure designed for agents, and made fully visible to humans. That is Mercury

jaggerxtrm's tweet photo. I have been actively using LLMs to help turn my ideas into real systems since Claude 3.5 Sonnet, the first model that made AI-assisted coding feel genuinely real to me. It was not that long ago, but considering how quickly models, tools and available resources are progressing, it already feels like another era.

About a year and a half ago, after a particular event in my life, I decided to dedicate much more time to developing and applying what I had learned through years of trading, and to understanding how agents could improve that work. During a ten-day hospital stay, with an iPad and a keyboard, I wrote more than 100 pages of plans, architecture and documentation around what would eventually become Mercury. A second project emerged naturally from the same work: a system for autonomous and coordinated agents, now called xtrm.

One of the things that bothered me from the beginning was the inevitable “You’re right…” that an agent gives you after it has already implemented the wrong thing. But what had actually failed? Was my request wrong? Was the context incomplete or badly structured? Had I failed to define the constraints? Or had the agent quietly taken its own direction, made assumptions and simply produced the wrong result?

I also noticed that continuing the same conversation after a serious mistake often led to progressively worse results. The model started behaving as if it were under pressure, almost like an employee who had been reprimanded and was now more concerned with avoiding another negative reaction than with doing the work correctly. It would agree too quickly, overcorrect, become excessively cautious or optimize for approval rather than accuracy. Before becoming a full-time trader, I worked in management, so I recognized the pattern. A language model obviously does not feel fear, but the resulting failure mode was surprisingly similar.

That observation became part of the reason xtrm exists. Agents need much more than longer prompts and more tokens. They need explicit context, boundaries, task contracts, evidence, review, deterministic validation, recovery paths and coordination. They also need a clear distinction between what is authoritative, what is an assumption and what still needs to be verified.

Finance and markets exposed an even larger problem. There is an enormous amount of financial information available, but much of what is most visible, repeated and likely to appear in model training data is retail-level information. It is often oversimplified, copied endlessly from one source to another, detached from actual market structure and sometimes simply wrong. Much of it has very little value for a professional trader.

This is particularly dangerous with language models because they are very good at producing fluent explanations. An answer can sound intelligent even when the framework underneath it is weak, the data are inappropriate or the reasoning is based on concepts that no serious practitioner would use in that way.

That is why I spent those 100+ pages describing how information should be structured from the point of view of someone who actually trades, and who has developed a fairly sensitive bullshit detector over the years. How should an agent reason about fixed income, curves, spreads, central banks, liquidity, volatility, positioning, market structure and macroeconomic data? Which sources are canonical? Which transformations are valid? Which assumptions must always be explicit? Which calculations should never be delegated to free-form language generation? What should be handled by deterministic infrastructure, what should be validated, and what should be preserved so that the work can be inspected, reproduced and resumed later?

A year and a half later, Mercury reflects an almost obsessive attention to those details. It is built on a substantial server, cloud and data stack, with high-quality quantitative and qualitative information, government and economic sources, market data, domain-specific transformations, quantitative tools, academic and canonical knowledge, industry-standard methods and validation from people who genuinely understand the mathematics involved.

This matters because language models are not naturally designed to analyze raw time-series data. They are not designed to look at an image of a chart and somehow produce analysis with a real and durable edge. There are now countless products that connect to TradingView, capture candles or chart images, send them to a model and return something that looks like analysis. That is not what Mercury is.

A candlestick chart is already a compressed visual rendering of underlying data. Asking a language model to infer sophisticated market structure from the pixels means discarding precision before the reasoning has even started. The model does not know what relevant information is missing, which transformations produced the chart, what happened elsewhere on the curve, which macro events occurred, how volatility changed, whether liquidity was abnormal or whether the apparent pattern has any statistical significance.

LLMs are far better at connecting dots than they are at manufacturing reliable dots from raw numerical information. They can synthesize, compare, contextualize and identify relationships extremely well, but only when the information they receive has already been structured correctly.

Mercury starts one layer earlier. The infrastructure retrieves, transforms, calculates and packages the information. The agent works with structured outputs, domain-specific methods and reliable tools instead of guessing from pixels. The human can then inspect the same evidence, verify what the agent saw, review the calculations and continue the work through a high-quality visual and functional platform.

Mercury is agent-first, but it is not human-absent. The principle is that the human should be able to see what the agent sees: not only the final answer, but also the data, assumptions, calculations, sources, intermediate artifacts and analytical path behind it.

The same principle applies to quantitative research. LLMs still perform poorly when they are expected to carry out unconstrained mathematics entirely through language. Mathematics is too broad and often requires forms of abstraction, rigor, creativity and critical reasoning that models do not possess consistently yet. But an LLM does not need to replace a mathematical system. It needs access to one.

With a solid quantitative infrastructure, an agent can help someone express an idea, translate it into formal assumptions, select appropriate methods, build a statistical model, test it, identify its weaknesses and determine whether it deserves further development. This allows someone who is not necessarily a mathematician, programmer or quant developer to apply an idea without pretending that statistical validity can simply be generated through language. The infrastructure remains responsible for calculation, validation and reproducibility. The model helps coordinate the reasoning.

I believe we are moving toward a period in which people will increasingly interact with the internet, software and data through agents rather than directly through websites and dashboards. The agent will search, retrieve, calculate, compare, organize and prepare information. The user will inspect, direct, question and decide.

Most financial platforms were designed for a human clicking through screens. Mercury is being designed for a world in which the primary consumer of the infrastructure may be an agent, while the human still retains full visibility and control. That means structured access through MCP, APIs and CLI tools. It means avoiding unnecessary token usage, returning compact but information-dense results, preserving sessions and artifacts, and allowing research to be resumed instead of disappearing inside an old conversation.

It also means giving agents access to financial knowledge that is more precise than the generic material contained in their training data, and eventually allowing users to preserve their own sessions, reports, charts, models and research artifacts in a space that remains accessible both to them and to their agents.

Some of you have heard me mention Mercury for several months while the details have remained intentionally limited. At the moment, it is available only to a small group of people. Soon, we will open access to a public beta for a limited period. There is already an application form on our website, but it will shortly be replaced by a more detailed version explaining the product, the current scope of the beta and the type of users we are looking for.

One thing should be clear: there are dozens of open-source and commercial financial dashboards, and most of them do roughly the same thing. They show familiar data to a human through slightly different charts, tables and interfaces. There is nothing inherently wrong with dashboards, but Mercury was not created to become another one.

It was built to expand what a trader can know, connect, test and investigate through agents. It was built to give those agents better data, better tools, better domain knowledge and better constraints, and to help traders search for genuine edge with far greater depth and rigor.

Not AI commentary over a candlestick chart. Not another collection of generic indicators. Not another interface showing the same information everyone already has.

Financial intelligence infrastructure designed for agents, and made fully visible to humans.

That is Mercury

4

10

2

4

998

blablaablaaa

@jaggerxtrm

Who to follow

Last Seen Users on Sotwe

Trends for you

Most Popular Users