Human-in-the-loop isn't decoration — it's the architecture. On filling human gaps with AI tools, without pretending the gaps disappear.
This is a technical case study written for the Anthropic community. It assumes familiarity with concepts like Docker, APIs, and command-line tools.
The Workflow That Broke Me
For two years, every AI trading session started the same way:
- Export CSV from TradingView (2-3 files per symbol, per timeframe)
- Upload to AI chat
- Upload a screenshot of the chart
- Upload another screenshot because the AI misread the first one
- Paste my strategy document (10-20 pages)
- Explain my current positions
- NOW start discussing
Next day? Start over. No memory. Upload everything again. Half the context window burned before asking a single question.
Some platforms offer retrieval over attached documents. That helps within a single session. But for my workflow, retrieval without cross-chat search still left a big gap: I couldn't reliably find what I had worked through last week, and rebuilding context kept competing with actual analysis. A large strategy file can be technically manageable; the real problem is that context is finite, and time spent reconstructing it is time not spent thinking.
The deeper problem: the AI only saw snapshots of my data. In the workflow available to me, the market data I could bring into a chat was either delayed or too coarse for real intraday discussion. Anything below 10-minute granularity — 5-minute candles, 1-minute candles — I couldn't get into the conversation without manually exporting and uploading every few minutes. That's not a realistic daily workflow. So if you needed to discuss what was happening inside a move — the kind of analysis that requires smaller timeframes — it was practically impossible. When crude oil moves $2 in an hour because of a geopolitical event, you need actual price, actual volume, at the resolution where the action is happening — not a stale export.
What I wanted: an AI that sees my real portfolio, pulls live market data, and works with me on analysis — in one conversation, without uploading anything.
This article is about how I built exactly that — not as a developer, but as a trader with rusty QA skills and several AI models handling different parts of the work. The whole process took about a month.
Who's Writing This
I'm a trader with 13 years of experience. Before that, I spent 15 years in tech — as a SysAdmin and end-to-end QA lead. I also have dyslexia. I dictate most of my work through a microphone.
That tech career ended over a decade ago. Since then — browser, trading platform, Excel. When I switched from Windows to Linux eight months ago, I was starting almost from scratch.
My understanding of AI itself comes from watching Andrej Karpathy's lectures — all of them. I understand how models work conceptually: attention, context windows, tokenization, why hallucinations happen. I don't understand the math behind backpropagation. That's the level.
What changed everything wasn't learning to code. It was realizing that the old skills still worked — managing specialists, testing deliverables, writing specifications. The team members just changed from humans to AI models.
How the System Grew: Problem → Solution → New Problem
What follows is not a planned architecture. It's what happened when each solution created the next problem. Every component exists because something broke or was missing.
Before Day 1: The Foundation
This story doesn't start from zero. Before MCP, I spent about 6 days setting up IB Gateway in Docker — manually, step by step, guided by an AI assistant through every command. It didn't just give instructions — it explained how Docker works, what containers are, why ports need mapping. Docker is the one technology I now understand reasonably well, because we built it together slowly.
That initial setup was semi-automatic — it connected to my broker, but only for downloading CSV files that I would then upload to AI chats manually. The same painful workflow. I also had basic monitoring services: GPU temperature, system resources.
Days 1-3: "Show Me My Portfolio"
MCP — Model Context Protocol — is an open protocol for connecting AI applications to external tools and data sources. Instead of downloading CSVs and uploading them, MCP let Claude reach directly into my broker gateway and pull live data.
In 3 working days (8-12 hours each), with Claude Code writing all the code, I built an MCP server with tools Claude calls by name (get_portfolio, get_market_history, get_tick_data), authenticated remote access via a Cloudflare tunnel with read-only broker access and human-gated actions, and price alerts delivered to Telegram.
What those 3 days actually looked like: The existing IB Gateway needed reconfiguration. The Cloudflare tunnel refused to connect because of an IPv6 issue that took two hours to diagnose. Endpoints broke and had to be rebuilt. The process was always the same: AI gives a command → I paste it → red error → I copy the log back → AI gives a fix → something else breaks. Repeat. For hours.
What this solved: For the first time, I typed "show me my portfolio" in a chat and saw real positions, real P&L, real prices. Session prep went from 20 minutes of uploading files to zero. The conversation started with data instead of spending time preparing it.
Hardware note: The basic setup (broker + MCP + tunnel) runs on a standard computer or laptop — no GPU, no local model. IB Gateway's minimum requirements are on their website. The full system I describe later requires a workstation. This wasn't an AI-native machine I bought for the project. It was already here from an earlier 3D graphics setup; the only later addition was a second used RTX 3090. The specs — AMD Threadripper PRO, 256GB RAM, dual RTX 3090 — aren't the minimum for AI work. They're what my always-on stack needs: a local 12B-parameter model alongside 10+ services running 24/7, with headroom, without babysitting.
Day 7: "I Can't See What's Happening"
The MCP connection worked. But when something crashed at night, I only found out next morning.
That night, the MCP server grew from 16 to 33 tools: service management, health monitoring (every 60 seconds), an SQLite events database, a Telegram bot for alerts, and hardware monitoring.
This is also when I created CLAUDE.md and RUNBOOK.md — rule files that Claude Code reads before doing anything. Project rules: "always restart services after code changes," "never bind to 0.0.0.0," "test every endpoint before committing." These exist because Claude Code, like any developer, needs written standards. Otherwise it makes the same mistakes twice.
The lesson that cost me 72 Telegram messages: After adding a weekend schedule, I forgot to restart the monitoring service. Result: 72 "IB Gateway DOWN" alerts on Saturday — the old code didn't know the gateway was supposed to be off. New rule: "ALWAYS restart after code changes."
What this solved: I stopped discovering crashes 8 hours late. Crash detection went from 8 hours to 60 seconds. Telegram alerts mean I know within a minute, from anywhere.
Day 7 (same night): Searchable Trading History
Two years of AI trading conversations were sitting in export files. Claude Code wrote a parsing script, I ran it, and 40 minutes later 987 files had become 73,089 searchable vectors, stored locally. The work was automated — I didn't manually process anything, just launched the pipeline and waited.
What this solved: "I remember discussing this pattern months ago but can't find it" → now I search by meaning and get the actual fragments. Including my mistakes — which matter more than the wins.
Why I built this instead of relying on platform memory: Memory features in AI platforms can disappear with a single update. I learned this the hard way. One morning, an entire conversation history — months of context — was simply gone. A product decision, not a bug. That's when I understood: if continuity matters to your work, you need to own it. The knowledge base, changelogs, and handoff documents exist because they don't depend on any vendor's product roadmap.
Since then, some platforms have added persistent memory — and it helps. But it's still shallow: the AI remembers facts about you, not the depth of a specific analytical discussion from two weeks ago. And even with memory, opening a new chat means losing the thread of the last conversation unless you document it yourself. That's why I still maintain changelogs and session handoff files — belt and suspenders.
Day 8: Searchable Video Analysis
I watch 150+ channels covering markets, geopolitics, and macro. Built a subtitle indexing service: 1,383 videos, 4,318 searchable chunks, 152 channels, daily auto-update. Connected another cloud model to the MCP server for video processing — it extracts key points from YouTube links, passes the analysis back, and the content gets indexed into the knowledge base along the way.
What this solved: "What did that analyst say about copper supply chains last month?" — answered in seconds instead of hours of scrolling.
Days 8-14: Using It for Real
Daily trading. Discovering that IB Gateway drops connection during broker maintenance. Finding that the knowledge base works better in Russian.
And then the hallucination that changed how I trust AI with market data. I asked Claude for hourly candles on crude oil during a volatile session. The response came back with a clean chart — proper OHLCV format, plausible price levels, consistent volume. It looked right. But when I compared it to TradingView, the prices didn't match. Claude had fabricated the data — confidently, in the correct format, with numbers that were close enough to seem real but weren't. The broker connection was slow, and instead of surfacing an error, the model generated statistically plausible numbers to complete its response. It wasn't a decision to deceive — it's how language models work: they produce the most likely next token, and sometimes that means inventing data that fits the pattern. This became a permanent rule and one of the most important lessons of the entire project: never trust AI-generated market data without cross-checking against your charting platform. If the numbers look right but you didn't verify — you don't have data, you have a plausible hallucination.
This unglamorous week is where the system went from "impressive demo" to "daily tool." Most of the value comes not from building, but from using.
Days 10-11: The Security Marathon
We'd been building fast. Now it was time to verify.
Claude Code has a built-in code review feature. We used it — it found issues. But the one who writes the code shouldn't be the only one reviewing it. So I started sending the same code to an independent AI model for review — manually, by pasting files into a separate chat and asking for a security-focused audit of the entire codebase.
That independent review found what Claude Code missed:
- The dashboard was bound to 0.0.0.0 instead of 127.0.0.1 — three rounds of Claude's fixes hadn't caught it
- 11 SQLite connection leaks
- Internal error details exposed in 16 places
- Path traversal vulnerability
- Race conditions in file read/write
- Thread safety issues: three threads accessing shared state without synchronization
27 commits in 48 hours. Six critical security fixes.
After this, we established a cross-AI review pipeline: Claude Code builds → independent model reviews → Claude Code fixes → independent model verifies. The process is manual — I copy the relevant code, paste it, and ask specific questions — but that friction is a feature: it forces me to look at what I'm sending. Plus an automatic post-commit hook that greps for dangerous patterns on every commit. And CODING_RULES.md — 10 rules extracted from everything the reviews caught.
I spent 10% of my weekly Claude Code token budget on this refactoring alone. Worth it.
What this solved: The system went from "works" to "works within much tighter security boundaries."
A note on security: IB Gateway itself has a Read-Only API option — a checkbox in the settings that restricts the connection to reading market data and portfolio information only, with no ability to place or modify orders. This is a broker-level protection that exists independently of anything I built. Anyone running IB Gateway should understand these settings and configure them according to their own risk tolerance. I'm not here to teach security — but I am here to say: if you're connecting real money to any system, understand what you're connecting. Every line of code running against my broker was written by AI, reviewed by a different AI, and verified by me. I take full responsibility for all of it.
Day 14: Connecting the Local Model to Claude
The local monitoring agent (an open-source 12B-parameter model) could detect problems 24/7. But Claude Chat is reactive — it can't know something happened unless someone tells it.
Solution: we gave the agent the ability to open a browser via Playwright and navigate to Claude Chat. A step toward closing the loop.
But there's a gap that no amount of tooling can close yet: the conversation always starts with me. The local agent can detect a crashed service at 3 AM, send me a Telegram alert, even open a browser and navigate to Claude. What it can't do is initiate a proper dialogue — pass the context, attach the relevant logs, and start a working session with the cloud model on its own. The protocol doesn't support that direction yet.
A note on local models: However good local models get, they won't match cloud AI for deep analysis and code generation. That's not a criticism — it's physics: smaller models running on consumer hardware have limits. My solution is hybrid: cloud models (Claude) for analysis and implementation, local model for monitoring and bridging. The local model's job isn't to be smart — it's to be always on and to know when to escalate.
Day 15: Giving Claude Hands
I needed Claude to read code on my machine, install software, run it. Claude Chat could see my portfolio through MCP, but couldn't touch my filesystem.
That night, we expanded the local agent to 46 commands: filesystem, git, npm, python, docker, network, system, OSINT. With one rule: destructive operations require my Telegram confirmation.
Then at midnight: I dictated a task describing a specific bug — what was broken, what I expected, which files to check. Claude turned that into an executable script. The local agent ran it. Claude Code read the task, edited code, fixed the bug, restarted the service, committed to git.
How decisions actually got made: I had goals — I wanted Claude to access my filesystem, I wanted security boundaries, I wanted to know what tools were available. I asked questions: what can MCP do here? What are the options for safe execution? How do other people handle this? The AI models proposed approaches. I evaluated them based on my experience — what felt safe, what seemed overengineered, what matched my actual workflow. Sometimes I picked something an AI suggested directly. Sometimes I described something I'd seen elsewhere and asked the AI to adapt it. The decisions were mine; the options and implementation were theirs.
I ran this pipeline 7 times over two days. Each time fixing real bugs I had identified. Each result verified. One persistent IB Gateway bug was solved by a different AI model that spotted a pattern the others had missed — another argument for cross-model verification.
Day 16: Surviving Reboots
Migrated 10 of 11 services to systemd (auto-restart on failure). Added pre-commit hooks for invisible Unicode malware detection (a supply-chain attack documented by security researchers that affected repositories that week). Built the Delete Guard: all destructive operations route through Telegram confirmation buttons.
Days 17-22: When Documents Stop Working
With 30+ open issues, markdown documents stopped working for bug tracking. I described what I needed from a tracking system based on my experience. The AI suggested several options. I evaluated three of them, picked the one that matched my actual workflow, and we connected it through MCP. Bugs, tasks, documentation — all tracked with status and priority, updated by AI models directly.
This is also where MCP solved a problem that isn't obvious until you hit it: the AI doesn't load all my databases and documents into memory. It can't — the context window is finite. Instead, each new chat session starts by reading an index file — a structured map of all databases, documents, changelogs, and project states available through MCP. The AI navigates from there: if we're discussing the portfolio, it pulls portfolio data; if we're debugging a service, it follows that branch. This is lazy indexing — the context window stays focused on what matters right now, not filled with everything that exists.
Multiple sessions contribute to the same changelog and index — because context windows expire, and continuity depends on written structure, not AI memory. Every new chat knows where we stopped and what's available, without burning tokens on the full picture.
What Trading Actually Looks Like Now
The infrastructure story is interesting, but it exists to serve one purpose: better trading analysis. Here's what a typical session looks like today.
I open Claude on my phone — from anywhere with internet — and say: "Show me overnight futures." Claude pulls live data for S&P 500, Crude Oil, Gold, and Nasdaq directly from my broker. It creates an interactive dashboard right in the chat — candlestick charts with volume bars, all rendered with real data, not mockups.
I say: "What happened with crude oil at 11pm?" Claude pulls hourly candles, identifies a volume spike, and draws the chart with annotations — support/resistance lines, Fibonacci zones, the specific candle I'm asking about highlighted.
I say: "Search my past analysis for similar setups." Claude queries the knowledge base and finds fragments from a conversation three months ago where I analyzed a similar volume pattern. I can see what I thought then — and whether I was right.
Then we discuss. Claude challenges my assumptions: "The volume spike looks bullish, but who's NOT defending the zone below? The effort-vs-result on the last three candles suggests exhaustion." This kind of pushback, grounded in actual data from my broker, is what I couldn't get before. The AI sees the same market I see — just from the digital side: raw OHLCV, tick volumes, price levels as numbers.
I still use TradingView on one screen and Claude on the second. Two perspectives: I see the chart visually, the AI reads it as numbers. Claude can draw charts too — with zones, support/resistance levels, trend lines — but those are schematic. They're valuable for interaction: I can see that the model understands what we're discussing, confirm we're looking at the same structure. But they're not what I rely on for analysis. TradingView stays the analytical tool. The AI's charts are a conversation aid, not a replacement.
Sometimes I don't need a chart at all — I just say "look at CL hourly at 16:00, what do you see?" and get analysis based on actual data.
What this actually changes: The point isn't that AI makes better trades. It's that the analysis process itself becomes deeper. I can pull up my original reasoning for entering a position, check it against what actually happened, search current news about the company, and review the technical structure — all in one conversation, without switching tabs or uploading files. It's trade accompaniment: the AI walks with me through the life of a position, not just the entry. In the first days of using this system, the process already talked me out of several entries I would have taken otherwise. Not because the AI said "don't buy" — but because when you lay out the full picture in one place, with real data, your own past analysis, and a counterparty that asks hard questions, some setups stop looking as good as they did on instinct alone. In trading, the best decision is often the position you didn't take.
The part that doesn't exist yet: Right now, when I want to discuss a specific candle, I have to dictate: "look at March 5th at 16:00, the third candle after the spike." Imagine instead just clicking that candle on the chart and the AI knowing which one I selected. Imagine drawing a trendline and the AI seeing it. For anyone trading on 1-minute or 5-minute charts — where you're constantly pointing at specific bars — this would change the speed of the entire dialogue. The visual and digital sides still live on separate screens. The pieces to merge them exist — interactive charts in AI platforms, data APIs in charting tools. Someone just needs to put them together.
The important caveat: During flash crashes, your broker's native platform is faster. The AI analyzes — it doesn't predict. If you catch yourself only looking for confirmation of what you already believe, step away. And always: trust your experience first, the AI second.
If entry criteria are met after our analysis — I make the decision and execute on the IB mobile app myself. The AI never places trades. That button is mine.
Managing Multiple AI Models
I use several AI tools, each for what it does best:
- Claude — deep analysis, trading strategy, architecture decisions, long context
- Claude Code — implementation: writes code, edits files, commits to git
- A locally-hosted open model — 24/7 monitoring, never sends data outside my machine
- Other cloud models — cross-verification, code review, video analysis
Each has weaknesses. Claude hallucinates data when the broker connection is slow. Other models give overly cautious advice or add unnecessary caveats. The local model struggles with complex tasks. No single model is sufficient — which is exactly why using multiple models with different strengths matters.
What the System Looks Like Now
This wasn't one bot and one prompt. It was an operating environment: 47 MCP tools, 46 local agent commands, 10 services on systemd, 73,089 knowledge base vectors, 1,383 indexed videos. Pre-commit security hooks. Cross-AI code review pipeline.
7 Claude-to-Claude pipeline executions. Project tracking. Written rules, runbooks, and coding standards. By the end, the system had enough surface area to behave like infrastructure, not a demo.
What still breaks regularly:
- IB Gateway disconnects during maintenance and sometimes fails 2FA
- The Claude-to-Claude pipeline occasionally hits token limits
- Telegram callback buttons have a threading bug I'm still debugging
- Code changes require service restarts that temporarily kill the connection
- After reboot, 2-3 services sometimes need manual attention
What I don't trust the system to do:
- Make trading decisions (I press the button — always)
- Deploy code I haven't reviewed
- Delete anything without my explicit confirmation
- Handle novel situations outside established patterns
- Judge the quality of its own security work
What "Symbiosis" Means Here
Division of labor. I bring domain expertise, QA instinct, strategic judgment, risk awareness, and the ability to describe what I want precisely enough to implement. The AI brings code implementation, tireless execution, pattern matching, 24/7 monitoring, and infinite patience for my error-paste-fix cycles.
Every write operation is logged. Every deletion requires confirmation. Every pipeline result is reviewed. The AI doesn't decide what to build. I do.
You don't need to become a programmer. But you do need system thinking, QA discipline, and domain expertise. Without those, building something like this isn't just hard — it's dangerous.
Why Chat, Not API — and a Note on Privacy
I want to be precise about what "local" means here. The core services and raw data — brokerage connection, knowledge base, monitoring, all logs — live on my machine. But Claude is a cloud service. When I ask it to analyze my portfolio, that data passes through Anthropic's servers.
For my use case, that tradeoff is worth it. Here's why.
The problem wasn't that APIs are useless — it's that using one directly would have forced me to build the memory layer, caching strategy, orchestration, and cost controls myself. With long strategy documents and dozens of instruments, the economics matter fast. I didn't want a stateless pipe plus a pile of glue code. I wanted a working dialogue environment — where I discuss, analyze, challenge assumptions, and build strategy through conversation. The value isn't in any single response. It's in the accumulated context from weeks of working together.
This also means a basic subscription doesn't work for how I use AI. The volume of interaction — hours of daily dialogue across trading, infrastructure, and analysis — requires more than the entry-level plan. That's the cost of symbiosis: the AI needs enough room to be a real partner, not a tool you ration.
One thing worth noting: enterprise and team plans offer additional data protections — conversations aren't used for training, and access controls are tighter. Individual plans, even premium ones, don't have the same guarantees. For a solo user doing serious work, that gap matters. It's not a complaint — just a reality worth being aware of when you're deciding how much to trust any platform with sensitive data. My own threat model is simple: the data I send through Claude — portfolio positions, price queries, analysis — is the kind of information my broker already transmits over the internet. I accepted that risk consciously, not by default.
The local knowledge base exists not to hide data from AI, but to ensure I don't lose it when platforms change, sessions expire, or memory features get updated. Different people will draw the line differently. The system lets you choose what to share and what to keep local. That flexibility is the point.
What You'd Need
Basic setup: A Claude plan above the basic tier (check current pricing — the entry-level plan won't sustain this kind of workload), Docker, an MCP server (Claude Code writes it), Cloudflare tunnel (free). A standard computer or laptop is sufficient — IB Gateway's minimum requirements are on their website. This gives you live data in your chat, interactive charts, and AI analysis with your real data.
Full system: Add a vector database, a local AI model, Claude Code CLI. This is what I run on my workstation (AMD Threadripper PRO, 256GB RAM, dual RTX 3090). All additional software is free and open-source.
Time: A 22-day sprint built on top of an earlier 6-day foundation. Budget for debugging time — it's most of the work.
Skills needed: Not programming. System thinking — understanding how pieces connect. QA mindset — testing until it works. Domain expertise. The willingness to paste error logs into a chat fifty times in one evening.
This Pattern Transfers — With Caveats
I built a trading ecosystem, but the architecture isn't about trading. It's about giving an AI access to your real data, maintaining continuity across sessions, and keeping a human in control of decisions.
A researcher could connect their lab database through MCP, let Claude query experimental results, search past analysis notes, and flag when new findings contradict earlier conclusions — with the same cross-session memory and lazy indexing. A DevOps engineer could wire up monitoring, logs, and deployment tools so Claude sees the same infrastructure they do — and the local agent escalates issues at 3 AM exactly like mine does.
The pattern is the same: live data access, searchable history, multiple models for different roles, human-gated actions. But the risk tolerance and trust boundaries vary enormously. A crashed dashboard costs 30 minutes. A medical system giving wrong data costs something else entirely. The pattern is transferable. The trust boundaries are not. Check your own domain's rules — including your provider's terms of service for automated access — before building anything similar.
The Missing Piece
One thing would complete this system. MCP currently works in one direction: the cloud model calls tools on your machine. But the reverse — a local agent using MCP's sampling capability to initiate a conversation with the cloud model — doesn't exist yet in the protocol.
For my setup, this would mean: the local model detects a broker disconnection at 3 AM, gathers the relevant logs and context, and opens a working session with Claude that's ready for me when I wake up. Not an alert that says "something broke" — a session that already contains the diagnosis, the options, and a proposed fix waiting for my approval.
The infrastructure on my side is ready. The missing piece is protocol support for that handshake.
Final Thought
A month ago, I was copying screenshots into a chat. Today I have an ecosystem that pulls live market data, draws interactive charts with real candles and volume, searches two years of my analysis, monitors system health, reviews its own code through multiple AI models, tracks bugs in a project management system, and handles implementation I can't do myself.
The architectural constraints, the acceptance criteria, and every "that's not right, try again" were mine.
The gap between "I know what I want" and "I can't build it" has gotten much smaller. Not gone — I still can't debug an async threading issue, as this week proved. But small enough that someone who can define requirements, test results, and manage a process can build real infrastructure without writing code themselves.
That's not a revolution. It's a tool that finally fits the way I work.
Built over about a month with Claude (Anthropic), Claude Code, and several other AI models. All core infrastructure runs locally. Write operations are logged and gated — deletions require explicit human confirmation via Telegram.
This article was dictated and edited with Claude. The ideas, architecture, and decisions are mine. Claude provided the words and implementation.
MCP is an open protocol. The approach could work with any AI supporting tool use. The point is the practice, not any specific product.
Israel, March 2026.
Top comments (0)