Before writing a single line of code, I had to answer the most important product question: what problem are we actually solving?

Investment research is slow because the work is fragmented across multiple sources. Financial performance lives in one system. Market sentiment is scattered across news feeds. Strategic context is buried in quarterly reports. Manual synthesis creates inconsistencies, introduces bias, and doesn’t scale.

So I reframed the problem: design an autonomous agent whose primary responsibility is decision support. That single framing decision changed the entire architecture.

Start with the charter, not the tools

Most LLM implementations are reactive by default. A prompt such as “You are a helpful assistant. Answer questions about stocks” produces a model that waits for specific instructions, asks clarifying questions, and provides minimal information.

I needed the opposite: a goal-oriented agent that takes initiative.

You are an autonomous Financial Research Analyst. Your primary goal is to generate a comprehensive investment analysis report, including three year performance data, current market sentiment, strategic positioning, and an actionable recommendation with confidence level, whether or not the user explicitly asks for each component.

This isn’t full autonomy yet. The agent still follows explicit instructions about what to gather. But it is no longer just responding to questions. It is working toward a defined outcome.

Design tools as actuators

I equipped the agent with four specialized tools:

  1. get_stock_price(ticker) for price, volume, and market cap
  2. get_stock_history(ticker, period) for historical performance
  3. search_financial_news(query) for current news
  4. analyze_sentiment(text) for sentiment scoring

I deliberately excluded fundamental data APIs from the MVP because they added complexity without improving initial decision quality. I also excluded social media sentiment because the signal was too noisy.

More tools create more failure modes. I chose constraint over coverage.

Define behavioral constraints

Autonomy without constraints leads to unpredictable behavior. I defined proactive behavior, reactive error handling, and transparency requirements.

  • Gather comprehensive data rather than only what was requested.
  • Check historical performance and recent news sentiment.
  • Make a clear recommendation with a confidence level.
  • Try an alternative approach after a tool failure.
  • State missing data and cite sources with timestamps.

These were not prompt decorations. They were product requirements designed to build trust.

Use architecture to enforce the charter

I implemented the workflow in LangGraph with an agent node, a tool node, and conditional routing. The agent decides which tools to call. The tool node executes them with error handling. Routing sends the result back to the agent until analysis is complete.

This creates a loop in which the agent can iteratively refine its analysis without user intervention.

Test behavior, not just output

A traditional reactive prompt asked clarifying questions and returned minimal information. The goal-oriented charter proactively used multiple tools and produced a structured report.

I also simulated an API timeout. The agent detected the failure, tried alternative data sources, acknowledged the gap, continued with available information, and reduced its confidence level.

It didn’t crash or give up. It adapted. That’s the difference between a script and an autonomous system.

What I learned

  1. The charter matters more than the model. A well-defined goal with clear constraints can outperform a smarter model with vague instructions.
  2. Autonomy requires explicit error handling. If an agent can’t handle tool failures gracefully, it is fragile.
  3. Transparency is a product feature. Recommendations need source citations and confidence levels.

Agent design is a product problem first and an engineering problem second. If you don’t get the charter right, no amount of clever code will save you.