I Built a Small Agentic Trading App. It Cost Me a Few Hours and About $0.20 Per Run.

Source: Dev.to

Why This Project Started

When I see articles and hear people talking about AI agents, orchestration frameworks, and multi‑agent architectures, my first instinct is: if you know code, you just need a few lines, a couple of API calls, and an LLM. That’s it. That’s your agent.

I wanted to test that instinct, so I mixed it with something I actually care about: trading.

The Desired Workflow

The idea was simple: an app that

1. Gets some input from me (optionally).
2. Calls a few APIs to gather market data and news.
3. Sends everything to an LLM with the right context.
4. Saves the output for future runs (a basic form of memory).
5. Sends me the result via email and push notification.

I’m not comfortable letting it place or cancel orders automatically—maybe later. For now I just want it to think and tell me what it thinks.

What the App Actually Does

Each run produces a concrete recommendation such as:

• WAIT
• BUY at a particular price (or NOW)
• SELL at a particular price (or NOW)
• Amend existing orders, etc.

It’s not a vague “the market looks bullish” – it’s an actionable next step with reasoning attached. I still make the final call, but the model does the legwork of pulling everything together into a decision.

Implementation Details

Stack

Core Flow

flowchart TD
    A[Start (cronjob)] --> B[Gather user input / manual overrides]
    B --> C[Fetch broker data (positions, pending orders)]
    C --> D[Pull news via Tavily]
    D --> E[Build prompt (dynamic variables inserted)]
    E --> F[Call Claude (Opus) via LangChain]
    F --> G[Generate run summary + recommendation]
    G --> H[Save summary to file (memory)]
    G --> I[Send email (Gmail) & push (Home Assistant)]
    I --> J[End]

Why LangChain?

• Partly to learn it.
• Partly because I want to extend the solution later (e.g., route first‑pass queries to Sonnet, then upscale to Opus).
• It’s a convenient abstraction, not a strict requirement—everything could be done without it.

Dynamic User Prompt

The prompt contains several runtime‑filled variables:

• Current position
• Pending orders
• Historical orders

These are populated via plain REST calls to my broker—no fancy orchestration needed.

Missing Historical Price Data

My broker doesn’t expose historical price data through its API, and I don’t want to pay a separate data provider.

For now the prompt doesn’t rely heavily on price charts or technical indicators. Instead it leans on:

• News
• Market commentary
• Analyst takes (all pulled in by Tavily)

This keeps the system simple and cheap. I’ll add a historical data source later.

Local Override Mode

When the app runs locally (not as a cronjob) I can:

• Paste in manual news items.
• Force a particular instrument price (e.g., “assume price = X”).

This is surprisingly useful for testing and for “what‑if” scenarios.

Memory (Run‑to‑Run Context)

• I don’t store the whole LLM output.
• The system prompt asks the model to produce a “run summary”—a condensed version of its reasoning and recommendation.
• This summary is saved to a file and injected into the next prompt.

Result: the model can see what it concluded last time, what it recommended, and whether conditions have changed. No vector DB, embeddings, or retrieval pipeline—just a plain text file.

Notifications

• Email: My own Gmail account sends messages to myself.
• Push: Home Assistant already knows how to push to my phone, so I simply call its API.

Both are simple, reliable, and already running in my environment.

Cost

• LLM usage: ~ $0.20 per run (Claude API for ingesting context, reading news, reasoning, and producing a recommendation).
• News data: Tavily’s free Researcher tier (more than enough for my current monthly run count).

The only real cost is the LLM. A professional trader might optimise further (local models, fine‑tuned financial models, latency concerns), but for me this is sufficient.

Closing Thoughts

A proper trader would probably want to:

• Use a local model for some steps.
• Look for a model fine‑tuned for financial reasoning.
• Optimise for latency and cost.

But for me, the current setup gives a repeatable, auditable, and inexpensive decision‑support tool that does exactly what I need: think, reason, and tell me what to do—while I retain the final authority.

Fun and Learn

Disclaimer: This is a personal learning project. Nothing here should be taken as financial advice. As a non‑native English speaker, I used an LLM to review and refine the language while keeping my original tone and ideas.

End‑to‑End Sketch

1. Cronjob triggers the Docker container on K3s (Raspberry Pi 5).
2. Broker API calls fetch current positions, pending orders, and order history.
3. Tavily tool (via LangChain) fetches relevant market news.
4. Prompt assembly: all dynamic data (including the previous run’s output as memory) is injected into the user prompt.
5. Claude Sonnet processes the full context and produces a recommendation.
6. Output is saved to a file (used as memory for the next run).
7. Email + push notification sent to me with the recommendation.
8. Human‑in‑the‑loop: I decide whether to act on the model’s recommendation.

That’s eight steps. Most of them are just API calls and string concatenation. The “agentic” part is really step 5 – the LLM reasoning over structured context with tool access. Step 8 is simply a person looking at his phone over coffee.

Why (or why not) a Fancy Orchestration Framework?

The obvious question: For a developer who can write code, why exactly do you need a fancy orchestration framework to build something like this?

There’s a market for “no‑code” AI agents and visual pipelines, but if you do write code, the essential pieces are:

• An LLM API
• A few REST calls (broker, news, notifications, etc.)
• String templating for prompts
• A file system (for memory)
• A way to send notifications (email, push, etc.)
• A container runtime (optional, but convenient)
• Logging (if you need audit or debug data)

That’s it. That’s the agent.

I’m not saying LangChain is strictly necessary either. I used it because I wanted to learn it and because the tool abstraction is convenient for the Tavily integration. I could have done the same thing with raw API calls and a hundred lines of Python.

The orchestration is just code. It always was.

The value of an LLM agent lies in:

• Prompt design
• Context assembly
• Quality of the model’s reasoning

Everything else is plumbing, and developers have been building plumbing for decades.