Deep Research and Development

For most of the current AI cycle, progress has been easy to describe: bigger models became more capable, better benchmarks justified higher prices, and the smartest model was usually the obvious choice for the hardest task. That relationship is beginning to loosen. The recent DeepSeek V4 comparison is interesting not simply because one model is cheaper than another. The more important observation is that a much smaller, cheaper model can now sit surprisingly close to a substantially larger one on capability, while post-training improvements can move performance far more than another enormous increase in model scale. The exact leaderboard positions will change. They always do. What matters is the direction. We are approaching a point where capable inference is cheap enough that the model itself stops being the main economic constraint. Once that happens, the question changes from: What is the smartest model we can afford? to: What is the cheapest system that can reliably complete the jo...

 The first version of this project was agent-centric. A general-purpose agent received an objective, gathered information, selected tools, delegated work and eventually approached execution. Security was therefore framed as a problem of constraining the agent: reduce tool access, isolate credentials, filter inputs, validate outputs and limit what downstream components would accept. That architecture became increasingly awkward. The more seriously I treated financial risk, the more capability I removed from the agent runtime. Broker credentials moved elsewhere. Generic network access became undesirable near execution. Multi-agent delegation remained useful for research but became harder to justify as authority moved closer to capital. The underlying problem was not simply that the agent was too powerful. It was that the agent owned the investment lifecycle. A general-purpose agent is designed to solve tasks. An investment system must maintain persistent financial state, react to ext...

Oh, man... Over the last few months I have been working through what started as a relatively straightforward question: what would it actually take to build a useful AI-native financial agent?  The first version used LangGraph and LangSmith and was deliberately conservative. The LLM could interpret the user's request, decide which operations were necessary and explain the result, but the financial calculations themselves lived in deterministic code. That separation was important because I did not want a language model improvising portfolio mathematics or inventing numbers.  From there I moved to OpenClaw , and the scope expanded considerably. Tools became more explicit, execution could persist beyond a single request, MCP provided a cleaner interface between the agent and deterministic financial services, and eventually I started experimenting with agent-to-agent designs: a research agent collecting information, another agent interpreting it, a portfolio component considering ...

 In the previous article , we moved from the idea of a Damodaran-style financial bot toward a practical multi-agent architecture: a system where different agents are responsible for data retrieval, assumptions, valuation, supervision, and report writing. That architecture gave us the direction of travel. The next question is more concrete:  how do we turn that architecture into a project that can be tested, evolved, and eventually connected to real financial data sources? The goal is to build a small, deterministic, testable version of the system that proves the shape of the application before we introduce live data, complex assumptions, model drift, flaky APIs, or LLM variability. A financial agent system can become difficult to debug very quickly. If an answer is wrong, the source of the problem may be the financial data, the normalization logic, the assumption layer, the valuation formula, the scenario model, the report writer, the agent instruction, or the orchestration pa...