DEV Community: Alexander Wondwossen

I'm in Grade 7 and I Built an AI Integration Hub with Google Gemini (Here's What I Learned)

Alexander Wondwossen — Tue, 03 Mar 2026 02:42:32 +0000

This is a submission for the Built with Google Gemini: Writing Challenge

Let me set the scene: I'm a 12-year-old in Toronto, Canada who codes random things for fun between school and photography sessions. I'm not a professional developer. I don't have a CS degree. I learn by experimenting, breaking things, and Googling error messages at weird hours.

So when I decided to build something real with Google Gemini — not just a chatbot demo, but an actual tool I'd use myself — I had no idea what I was getting into.

The result is Conductor: an AI integration hub and CLI that connects Gemini (and other AI providers) to real-world tools through a single interface. You install it in one line, configure your provider, and suddenly Gemini can check the weather, look up crypto prices, monitor your system stats, translate text, do DNS lookups, and way more — all from your terminal or even Telegram.

Here's what that journey actually looked like.

What I Built with Google Gemini

The core problem I kept running into: every AI integration felt like starting from scratch. Want Gemini in your terminal? Build a CLI. Want it on Telegram? Build a bot. Want it to actually do things, not just chat? Add tools one by one. It was repetitive and fragmented.

Conductor is my answer to that. Think of it like a conductor at an orchestra — it doesn't play the instruments, it coordinates everything so they work together.

Here's what it can do:

Multi-provider AI in one CLI — Switch between Gemini, Claude, GPT-4o, and even local Ollama models with a config change. Conductor abstracts away the differences so you talk to them all the same way.

13 built-in plugins, zero API keys needed — This was important to me. I didn't want something that required you to sign up for 10 different services just to get started. All plugins work out of the box:

Plugin	What it does
`weather`	Real-time weather + 7-day forecast via Open-Meteo
`crypto`	Prices, trending coins, search via CoinGecko
`system`	CPU, memory, disk, process monitoring
`translate`	50+ languages via MyMemory
`network`	DNS lookup, IP geolocation, reverse DNS
`github`	User profiles, repos, trending
`calculator`	Math, unit conversion, date math
`colors`	Hex/RGB/HSL conversion, WCAG contrast checking
`text-tools`	JSON formatting, regex testing, case transforms
`hash`	SHA/MD5, Base64, UUID, password generation
`url-tools`	Link expansion, status checks, header inspection
`fun`	Jokes, trivia, cat facts (important)
`timezone`	World clock, timezone conversion

MCP server — This is where Gemini really shines. Conductor can run as an MCP (Model Context Protocol) server, which means Gemini can call any of these tools as native functions. Instead of Gemini just knowing about the weather, it can check the weather. Instead of estimating a math answer, it calculates it.

Telegram bot — Run conductor telegram start and you've got a Gemini-powered bot in your pocket. Chat with it from your phone, ask it to check the weather or convert currencies, get real answers.

Encrypted keychain — I took security seriously. API keys are encrypted at rest with AES-256-GCM, and the key is derived from your machine's hardware ID using scrypt. Your credentials only decrypt on the machine that created them.

Install it yourself:

# macOS / Linux
curl -fsSL https://raw.githubusercontent.com/thealxlabs/conductor/main/install.sh | bash

# Windows (PowerShell)
irm https://raw.githubusercontent.com/thealxlabs/conductor/main/install.ps1 | iex

Then:

conductor ai setup     # pick Gemini
conductor ai test      # make sure it works
conductor mcp start    # expose tools to Gemini

🔗 github.com/thealxlabs/conductor

Demo

Here's what using Conductor with Gemini actually looks like:

$ conductor ai setup
✓ Provider set to: Gemini
✓ Model: gemini-2.0-flash

$ conductor ai test
→ Asking Gemini: "What's 2+2 and what's the weather like in Tokyo?"
✓ Gemini used [calculator] → 4
✓ Gemini used [weather] → Tokyo: 12°C, partly cloudy
Response time: 1.3s

The moment Gemini autonomously chose to call two different tools to answer one question — without me telling it to — was genuinely exciting. That's the power of MCP working properly.

What I Learned

Building for real is completely different from tutorials

Every tutorial I watched made things look clean. Variables always work. APIs always respond. Types always line up. Building Conductor taught me that real projects are messier — and way more satisfying to get right.

TypeScript is humbling. I chose TypeScript for Conductor because I wanted type safety across the whole codebase. What I didn't expect was how opinionated TypeScript gets when you're working with dynamic things like AI API responses, plugin schemas, and streaming data. I spent more time fixing type errors than writing features in the first week. By the end, I understood why it's worth it.

Multi-provider abstraction is genuinely hard. Gemini, Claude, and OpenAI all have function/tool calling — but their APIs handle it differently. Streaming works differently. Error shapes are different. Creating a single provider interface that felt consistent across all of them meant I had to really understand each one deeply before I could abstract over them. This was the hardest technical challenge in the whole project.

Security isn't optional, even in hobby projects

When I first sketched out Conductor, I was going to just store API keys in a plain JSON file. Then I thought about it more. These keys give access to AI accounts with billing attached. I learned about AES-256-GCM encryption, how to derive keys with scrypt from hardware identifiers, and why machine-binding matters. The keychain implementation took longer than expected but I'm proud of it — and it taught me a lot about how real applications handle secrets.

Cross-platform development will test your patience

Getting Conductor working identically on macOS, Linux, and Windows was the most underestimated part of the project. Shell scripts behave differently. Path separators behave differently. Process spawning behaves differently. File permissions mean different things. I now have a lot more respect for anyone who ships truly cross-platform software. The Windows PowerShell install script alone taught me more than I expected.

MCP is a glimpse at the future of AI

Before this project, I thought of AI as something you talk to. After building the MCP server integration, I think of it differently — as something that can act. When Gemini decides on its own to call the weather plugin and then the timezone plugin to answer a single question, it's not just chatting. It's reasoning about what tools it needs and using them. That shift in perspective changed how I think about AI's role in software.

As a kid who codes, imposter syndrome is real — and you have to build through it

I almost didn't ship this because I kept thinking "who am I to build something like this?" I'm in Grade 7. I don't have internships or a degree. I'm just a kid from Toronto who learned to code by experimenting.

What helped: remembering that every developer started somewhere, and the only way to get better is to build real things and share them. This project is the most technically complex thing I've built. It has flaws. But it works, it's useful, and I made it.

Google Gemini Feedback

I want to be honest here, because I think candid feedback is more useful than just praise.

What worked really well

Tool/function calling is excellent. The Gemini function calling API is clean and well-designed. Defining tools as JSON schemas and having the model decide when to invoke them felt intuitive. Once I understood the pattern, integrating new Conductor plugins was straightforward. Gemini's tool selection accuracy was impressive — it almost always picked the right tool for the right job.

Speed on flash models. gemini-2.0-flash is genuinely fast. For a CLI tool where you're waiting for a response, speed matters a lot. Using the flash model for Conductor's day-to-day interactions felt snappy in a way that made the tool feel good to use, not like waiting for an AI.

Quality of reasoning with tool results. When Gemini receives tool results back (e.g., raw weather JSON), it synthesizes them into natural, helpful responses rather than just dumping the data. This made the Telegram bot experience feel genuinely conversational rather than robotic.

Gemini handles context well. In multi-turn Telegram conversations, Gemini kept track of context naturally. If you asked about the weather and then said "what about tomorrow?", it understood the reference without needing everything repeated.

Where I ran into friction

Streaming + tool use together is tricky. This was my biggest technical pain point. When streaming is enabled and Gemini calls a tool mid-stream, the response format gets complex — you get partial tool call deltas that need to be assembled before you can make the tool call. The documentation for this specific case was sparse. I ended up disabling streaming during tool use and re-enabling it for the final response, which works but isn't ideal.

Rate limits hit fast during stress testing. When I was testing the Telegram bot with rapid-fire messages, I hit rate limits quickly on the free tier. The error messages weren't always clear about whether I was hitting requests-per-minute or tokens-per-minute limits. Better rate limit error messaging would help developers build more resilient apps.

No native session/conversation persistence. Every Gemini API call is stateless — you have to send the full conversation history each time. For Conductor's Telegram bot, this means the conversation history grows with every message and eventually you're sending a lot of tokens just to maintain context. I'd love a managed session API that handles history server-side. I built my own conversation manager to work around this, but it added complexity.

Model string versioning is confusing. Knowing which model string to use (gemini-pro, gemini-1.5-pro, gemini-2.0-flash, etc.) and what the differences are in terms of capability and cost required a lot of reading across different docs pages. A clearer, centralized comparison would save time.

What's Next

Conductor started as a personal experiment but I want to keep building it. Things I'm planning:

Voice mode — pipe Conductor through a TTS/STT layer for a real Jarvis-style interface
Plugin marketplace — let people write and share their own plugins
Web dashboard — a simple UI to manage providers, plugins, and conversation history
More providers — Groq, Mistral, Cohere

Most of all, I want other people to use it. If you install Conductor and find a bug, I want to know. If you have an idea for a plugin, open an issue. This is open source and I'm still learning — feedback from real users is how I get better.

Building Conductor taught me more than any tutorial ever could. And using Gemini as the AI backbone of a real tool — not just a playground project — gave me a much clearer picture of where the technology is genuinely impressive and where it still has room to grow.

If a Grade 7 kid from Toronto can build something like this independently, imagine what's possible when more people start treating AI as a tool to extend their own capabilities rather than just something to chat with.

That's the most exciting thing I learned from this whole project.

🔗 github.com/thealxlabs/conductor

— Alexander Wondwossen (@thealxlabs), Toronto 🇨🇦

I Built an AI Integration Hub at 13 — Here's What I Learned

Alexander Wondwossen — Tue, 03 Mar 2026 02:29:46 +0000

I'm Alexander, I'm 13, and I've been coding for a few years across Python, TypeScript, Swift, and Bash. Last month I shipped something I'm actually proud of: Conductor — a TypeScript AI engine that connects Claude, GPT-4o, Gemini, and Ollama to your real-world tools like Gmail, Spotify, GitHub Actions, Notion, and HomeKit.

As of today it has 27 plugins and 150+ tools. Here's the honest story of how it got there.

What Conductor actually is

At its core, Conductor sits between you and your AI model. You say something in plain English, Conductor figures out which tools to call, chains them together, and gives you a result.

Example:

"Find my 3 latest unread emails, add any urgent ones to my calendar, then DM me on Slack."

Conductor handles:

gmail_list() → fetches emails
AI classifies which ones are urgent
gcal_create_event() → creates the event
Sends a Slack message summarizing what it did

And this works whether you're talking to it through Claude Desktop (via MCP), a Telegram bot, or a Slack bot. Same engine, three interfaces.

The architecture that actually worked

I went through a few redesigns before landing on something I was happy with. The final structure has four main parts:

Core (src/core/) — The orchestrator. Initializes config, database, plugins, and AI on startup. Owns the proactive loop.

AI Layer (src/ai/) — Each provider (Claude, OpenAI, Gemini, Ollama, OpenRouter) implements the same interface: complete(), test(), and parseIntent(). Switching models is one command: conductor ai switch gemini.

Plugin System (src/plugins/) — Every plugin exports a Plugin object with a name, description, and array of tools. Each tool declares an input schema (JSON Schema) and an async execute() function. To add a new plugin you just implement the interface and register it in one index file — it automatically shows up across MCP, Slack, and Telegram.

Interfaces — MCP server (stdio mode for Claude Desktop), Slack bot, Telegram bot. All read from the same plugin registry.

The agent loop runs up to 15 tool-calling iterations per conversation turn before halting. It keeps the last 30 messages of history per user in SQLite.

The thing I'm most proud of: Proactive Mode

Proactive Mode is an autonomous reasoning loop that runs on a schedule (every 30 minutes by default) without any user prompts.

Each cycle:

Gathers context — CPU/RAM/disk stats, unread Gmail count, upcoming calendar events, recent activity
Sends it to the AI with instructions to identify problems and act on them
Holds sensitive actions for human approval before executing
Sends you a summary via Slack or Telegram

So Conductor might notice your disk is 85% full, archive some old logs, and send you a Slack message saying what it did — all without you asking.

The approval gate system was the hardest part to get right. When the AI tries to call a tool marked requiresApproval: true, the agent loop pauses and notifies you. You reply /approve <id> or /deny <id> and it continues. This means proactive mode can be genuinely autonomous without being scary.

What I got wrong the first time

Security. My first version stored API keys in plain JSON in ~/.conductor/config.json. That's obviously bad. I rewrote the credential system to use AES-256-GCM encryption with a key derived from the machine's hardware ID via scrypt. Keys are stored in ~/.conductor/keychain/ with 0700 permissions and never appear in config.json.

The agent loop limit. Early on I didn't cap the tool-calling iterations. The AI would sometimes get into a loop and run indefinitely. 15 iterations turned out to be the right balance — enough to handle complex multi-step tasks, but a clear hard stop.

Persona routing. Originally every request went to the same system prompt. Adding four personas (Coder, Social, Researcher, General) with automatic classification improved response quality noticeably. The AI classifies the request first with a fast call, then routes to the right tool set with the right system prompt.

What's still broken / what I want to fix

Honest list:

Error messages when API keys are missing are still too cryptic (I actually just opened a good first issue for this)
conductor plugins list doesn't show tool counts or descriptions in verbose mode (another good first issue)
No CONTRIBUTING.md yet, which makes it hard for new contributors to get started
Test coverage is thin outside of unit tests for individual tools

The stack

TypeScript throughout
Commander.js for the CLI
sql.js for SQLite (conversation history, memory, activity logs)
@slack/bolt for the Slack bot
telegraf for the Telegram bot
Model Context Protocol (Anthropic's open standard) for Claude Desktop integration

The installer is a 14-step interactive bash/PowerShell script that sets up everything — AI providers, Google OAuth, Slack/Telegram tokens, Claude Desktop MCP config. Every step is optional and skippable. It's fully idempotent so re-running it is safe.

Install

# macOS / Linux
curl -fsSL https://conductor.thealxlabs.ca/install.sh | bash

# Windows (PowerShell)
irm https://conductor.thealxlabs.ca/install.ps1 | iex

Or check it out on GitHub: thealxlabs/conductor

Looking for contributors

I'm actively looking for people to help build this out. The issues I just opened are genuinely beginner-friendly:

#14 — Add --verbose flag to conductor plugins list
#15 — Write CONTRIBUTING.md
#16 — Better error handling for missing API keys on startup

If you're a student or early-career dev who wants to contribute to a real TypeScript project with an actual user base, hit me up. I'm @thealxlabs on X.

I'm 13 and I built this mostly during evenings and weekends in Toronto. If you have questions or feedback, I'm genuinely open to it — drop a comment or open an issue.