Deep Research and Development

 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...

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? ( Medium ) This article continues from that point by focusing on the proof-of-concept implementation. The goal is not to build a production-grade valuation platform in one jump. 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. That distinction matters. A financial agent system can become difficult to debug very quickly. If an answer is wrong, the source of th...