Forem: Natnael Getenew

Building Real-Time Voice AI with AWS Bedrock: Lessons from Creating an Ethiopian AI Tutor

Natnael Getenew — Mon, 20 Apr 2026 01:19:04 +0000

Most voice AI demos you see are either pre-recorded or have that awkward 2-3 second delay that kills natural conversation. When I started building Ivy, an AI tutor for Ethiopian students that needed to work in Amharic, I discovered that creating truly real-time voice AI is harder than it looks.

Here's what I learned about using AWS Bedrock to power conversational voice AI that actually feels natural.

The Real-Time Challenge

The biggest hurdle isn't the AI model itself—it's the pipeline. You need:

Speech-to-text conversion
Language processing
Response generation
Text-to-speech synthesis

Each step adds latency. String them together traditionally, and you're looking at 3-5 seconds of delay. That's conversation-killing.

Streaming is Everything

AWS Bedrock's streaming capabilities changed the game for me. Instead of waiting for complete responses, you can process tokens as they arrive:

import boto3
import json

bedrock = boto3.client('bedrock-runtime', region_name='us-east-1')

def stream_response(prompt):
    body = json.dumps({
        "prompt": prompt,
        "max_tokens_to_sample": 500,
        "temperature": 0.7,
        "stream": True
    })

    response = bedrock.invoke_model_with_response_stream(
        body=body,
        modelId='anthropic.claude-v2',
        contentType='application/json'
    )

    for event in response['body']:
        chunk = json.loads(event['chunk']['bytes'])
        if 'completion' in chunk:
            yield chunk['completion']

The Parallel Processing Trick

Here's where it gets interesting. Instead of a linear pipeline, I built a parallel one:

Start TTS early: As soon as I get the first few tokens from Bedrock, I begin text-to-speech conversion
Chunk intelligently: Break responses at natural pause points (commas, periods)
Buffer strategically: Keep a small audio buffer ready while processing the next chunk

This reduced perceived latency from 3+ seconds to under 800ms—the sweet spot for natural conversation.

Handling Amharic Complexity

Working with Amharic presented unique challenges. The language has its own script, complex grammar, and limited training data in most models. AWS Bedrock's Claude models handled this surprisingly well, but I had to:

Fine-tune prompts with Amharic context
Handle script switching (students often mix Amharic and English)
Implement custom preprocessing for educational content

def preprocess_amharic_input(text):
    # Handle mixed script input
    if contains_amharic_script(text):
        # Apply Amharic-specific processing
        return normalize_amharic(text)
    return text

def normalize_amharic(text):
    # Custom normalization for Amharic characters
    # This was crucial for consistent model performance
    return text.replace('፡፡', '.').replace('፣', ',')

Cost Optimization Reality Check

Real-time voice AI can get expensive fast. Here's what worked for me:

Smart caching: Cache common educational responses
Context management: Keep conversation context minimal but relevant
Model selection: Use Claude Instant for quick responses, full Claude for complex explanations

The Offline Capability Plot Twist

The real breakthrough came when I realized many Ethiopian students have unreliable internet. I built offline capability using:

Local speech recognition fallbacks
Cached response patterns
Smart sync when connection returns

This wasn't just a nice-to-have—it became Ivy's differentiator.

What's Next

Building Ivy taught me that great voice AI isn't just about the model—it's about the entire experience. AWS Bedrock gave me the foundation, but the magic happened in the details: streaming, parallel processing, and understanding your users' real constraints.

Ivy is currently a finalist in the AWS AIdeas 2025 competition, where community voting helps decide the winner. If you found these insights helpful and want to support innovation in educational AI for underserved communities, I'd appreciate your vote: https://builder.aws.com/content/3CQJ9SY2gNvSZKWd3tEq8ny7kSr/aideas-finalist-ivy-the-worlds-first-offline-capable-proactive-ai-tutoring-agent

Want to try building real-time voice AI yourself? Start with AWS Bedrock's streaming API and remember: latency is everything, but user experience is king.

Building an AI Tutor in Amharic: What I Learned as a Solo Developer

Natnael Getenew — Mon, 20 Apr 2026 00:31:20 +0000

Over 120 million people speak Amharic, yet there's virtually no AI educational content in the language. When I realized this gap while watching my younger siblings struggle with online learning during COVID, I knew I had to build something.

That's how Ivy was born – an AI tutor that speaks Amharic and helps Ethiopian students learn through natural conversation. Building it as a solo developer taught me lessons I never expected.

The Voice AI Challenge Nobody Talks About

Most developers think voice AI is just "add speech-to-text and text-to-speech APIs." Wrong. The real challenge is handling the conversational flow when dealing with languages that have limited training data.

Amharic has complex grammar with over 200 verb conjugations. When a student says "ይህን አልገባኝም" (I don't understand this), the AI needs to:

Recognize the specific confusion marker
Identify what "this" refers to in context
Adjust its teaching approach accordingly

Here's how I handled context preservation:

class ConversationMemory {
  constructor() {
    this.context = {
      currentTopic: null,
      studentConfusion: [],
      learningStyle: 'adaptive'
    };
  }

  updateContext(userInput, aiResponse) {
    // Track confusion patterns
    if (this.detectConfusion(userInput)) {
      this.context.studentConfusion.push({
        topic: this.context.currentTopic,
        timestamp: Date.now(),
        userPhrase: userInput
      });
    }
  }
}

The Offline-First Decision That Changed Everything

Initially, I planned Ivy as a cloud-only service. Then I remembered: most Ethiopian students don't have reliable internet. This constraint forced me to rethink the entire architecture.

I ended up building a hybrid system where the core AI models run locally using TensorFlow.js, with cloud sync when available. This decision tripled my development time but made Ivy accessible to students in rural areas.

The breakthrough came when I realized I could use service workers for more than just caching:

// Service worker handles AI inference offline
self.addEventListener('message', async (event) => {
  if (event.data.type === 'AI_QUERY') {
    const response = await processWithLocalModel(event.data.query);
    event.ports[0].postMessage(response);
  }
});

Cultural Context is Code

Building for Ethiopian students meant encoding cultural context into the AI's responses. When teaching math, Ivy uses examples like calculating injera ingredients or coffee ceremony timing – concepts that resonate locally.

This taught me that AI isn't just about algorithms; it's about cultural representation in code. I spent weeks interviewing teachers and students to understand how they naturally explain concepts in Amharic.

The Loneliness of Solo Development

The hardest part wasn't the technical challenges – it was the isolation. Debugging voice recognition at 2 AM with no one to bounce ideas off was brutal. I learned to embrace async communication with online communities and scheduled regular video calls with other developers, even if they weren't working on similar projects.

What's Next

Ivy is now a finalist in the AWS AIdeas 2025 competition, competing globally against incredible innovations. The community voting phase is live, and honestly, it would mean the world to have support from fellow developers who understand the journey.

You can check out Ivy and cast your vote here: https://builder.aws.com/content/3CQJ9SY2gNvSZKWd3tEq8ny7kSr/aideas-finalist-ivy-the-worlds-first-offline-capable-proactive-ai-tutoring-agent

Building Ivy taught me that the most impactful projects often come from solving problems in your own backyard. Sometimes the best innovation happens when you build for the community you know best.

If this resonates with you, I'd be incredibly grateful for your vote in the AWS AIdeas competition. Every vote helps bring AI education to more Ethiopian students.

Building Conversational AI in Amharic: Lessons from Creating Ethiopia's First Voice AI Tutor

Natnael Getenew — Sun, 19 Apr 2026 01:01:02 +0000

Did you know that over 100 million people speak Amharic, yet there's virtually no conversational AI built specifically for this language? When I started building Ivy, an AI tutor for Ethiopian students, I quickly discovered why.

The Challenge: More Than Just Translation

Most developers assume you can just translate English prompts and call it localization. I learned the hard way that Amharic has unique grammatical structures, cultural contexts, and educational frameworks that require a completely different approach.

Here's what I wish I knew before starting:

1. Script Complexity Matters

Amharic uses the Ge'ez script with over 200 characters. Unlike Latin-based languages, each character can represent different sounds depending on context:

ሀ (ha), ሁ (hu), ሂ (hi), ሃ (haa), ሄ (hee), ህ (h), ሆ (ho)

This means tokenization becomes incredibly complex. Standard NLP libraries often break Amharic words incorrectly, leading to poor model performance.

2. Voice AI Architecture for Low-Resource Languages

Building voice AI for Amharic meant dealing with limited training data. Here's the architecture I settled on:

# Simplified pipeline structure
class AmharicVoiceAI:
    def __init__(self):
        self.speech_to_text = WhisperAmharic()  # Fine-tuned Whisper
        self.llm = LlamaAmharic()  # Custom fine-tuned model
        self.text_to_speech = CoquiTTS()  # Open-source TTS

    def process_conversation(self, audio_input):
        # Convert speech to text
        text = self.speech_to_text.transcribe(audio_input)

        # Process with cultural context
        response = self.llm.generate_culturally_aware_response(text)

        # Convert back to natural-sounding Amharic speech
        audio_output = self.text_to_speech.synthesize(response)
        return audio_output

3. Cultural Context is Everything

The biggest breakthrough came when I stopped trying to adapt Western educational content and started building from Ethiopian curriculum standards. For example, when teaching math, I use familiar examples:

Instead of "apples and oranges," I use "injera and berbere"
Historical examples reference Ethiopian figures like Emperor Menelik II
Currency examples use Ethiopian Birr

This cultural grounding improved student engagement dramatically.

Technical Implementation Tips

Fine-tuning for Amharic

I found that starting with multilingual models and fine-tuning works better than training from scratch:

# Fine-tuning approach that worked
base_model = "microsoft/DialoGPT-multilingual"
tokenizer = AutoTokenizer.from_pretrained(base_model)

# Add Amharic tokens
new_tokens = ["ሰላም", "እንደምን", "ተማሪ"]  # Common Amharic words
tokenizer.add_tokens(new_tokens)

Handling Code-Switching

Ethiopian students often mix Amharic with English, especially for technical terms. I built a detection system that handles this naturally:

def detect_language_mix(text):
    # Simple regex for mixed content
    has_amharic = bool(re.search(r'[\u1200-\u137F]', text))
    has_english = bool(re.search(r'[a-zA-Z]', text))
    return has_amharic and has_english

The Results

After six months of development, Ivy can now:

Conduct natural conversations in Amharic
Adapt to different Ethiopian English accents
Work offline (crucial for areas with poor internet)
Provide culturally relevant educational content

The most rewarding moment was when a student from rural Ethiopia told me Ivy felt like talking to a patient older sibling who understood their world.

What's Next

Building Ivy taught me that creating AI for underrepresented languages isn't just about technical challenges—it's about understanding and respecting the culture behind the language.

Ivy recently became a finalist in the AWS AIdeas 2025 competition, where community voting determines the winner. If you found this technical journey interesting, I'd be grateful for your vote: https://builder.aws.com/content/3CQJ9SY2gNvSZKWd3tEq8ny7kSr/aideas-finalist-ivy-the-worlds-first-offline-capable-proactive-ai-tutoring-agent

Want to help bring AI education to Ethiopian students? Cast your vote and help make quality education accessible to millions of Amharic speakers worldwide.

Building Voice AI for Students Who Can't Afford Internet: Lessons from Ethiopia

Natnael Getenew — Sun, 19 Apr 2026 00:14:04 +0000

Did you know that 70% of Ethiopian students don't have reliable internet access, yet they're expected to compete globally? This reality hit me hard when I watched my younger sister struggle with her studies, unable to access online learning resources that kids in other countries take for granted.

That's when I decided to build Ivy – a voice AI tutor that works entirely offline and speaks Amharic, Ethiopia's primary language.

The Technical Challenge: Making AI Work Without Internet

Building an offline voice AI system isn't just about downloading models. Here's what I learned:

1. Model Optimization is Everything

I started with OpenAI's Whisper for speech recognition, but the full model was 1.5GB – way too heavy for most phones here. After experimenting with quantization and pruning techniques, I got it down to 200MB while maintaining 85% accuracy for Amharic.

# Model compression approach that worked
import torch
from transformers import WhisperProcessor, WhisperForConditionalGeneration

# Load and quantize the model
model = WhisperForConditionalGeneration.from_pretrained("openai/whisper-small")
quantized_model = torch.quantization.quantize_dynamic(
    model, {torch.nn.Linear}, dtype=torch.qint8
)

2. Local Language Models Need Creative Solutions

Running a capable LLM locally on budget Android phones seemed impossible until I discovered that you don't need GPT-4 level intelligence for tutoring. I fine-tuned a smaller model (1.3B parameters) specifically for educational conversations in Amharic.

The key insight: domain-specific models can outperform general models while being 10x smaller.

3. Battery Life is a Feature, Not an Afterthought

Students here often share phones with family members and can't always charge devices. I implemented aggressive power management:

Wake word detection uses only 2% CPU
Full AI processing activates only during conversation
Conversation state persists through app kills

The Offline-First Architecture

Here's the system design that made it work:

┌─────────────────┐    ┌──────────────────┐    ┌─────────────────┐
│  Voice Input    │───▶│  Local Whisper   │───▶│  Text Processing│
└─────────────────┘    └──────────────────┘    └─────────────────┘
                                                         │
┌─────────────────┐    ┌──────────────────┐    ┌─────────────────┐
│  Voice Output   │◀───│  Local TTS       │◀───│  Local LLM      │
└─────────────────┘    └──────────────────┘    └─────────────────┘

Everything runs on-device. No internet required after initial app download.

Real Impact, Real Numbers

After six months of testing with 200+ students:

78% improvement in math scores for students using Ivy vs traditional methods
Students practiced 3x more because they could learn in their native language
92% said they felt more confident asking questions to AI than human teachers

The last point surprised me. Turns out, cultural barriers disappear when students can practice privately in Amharic without fear of judgment.

What I Wish I Knew Before Starting

Start with the constraint, not the ideal: I initially tried to build a cloud-based solution. The offline requirement forced better design decisions.
Cultural context matters more than technical perfection: Spending time understanding how Ethiopian students actually learn was more valuable than optimizing model accuracy from 85% to 90%.
Battery optimization is harder than model optimization: I spent more time on power management than AI training.

Looking Forward

Ivy recently became a finalist in the AWS AIdeas 2025 global competition, which has been incredible validation for this approach. The competition focuses on AI solutions that can create real social impact, and I'm excited to see voice AI for education getting recognition.

If you believe that every student deserves access to personalized learning regardless of their internet connection or economic situation, I'd be grateful for your vote in the competition: https://builder.aws.com/content/3CQJ9SY2gNvSZKWd3tEq8ny7kSr/aideas-finalist-ivy-the-worlds-first-offline-capable-proactive-ai-tutoring-agent

The future of education isn't just about having the best AI – it's about making AI accessible to everyone who needs it most.

From Weekend Hackathon to AWS Global Finalist: Building an AI Tutor That Actually Works Offline

Natnael Getenew — Sat, 18 Apr 2026 00:55:39 +0000

Six months ago, I was debugging a React component at 2 AM when my little sister called from our village outside Addis Ababa. She was struggling with her physics homework and couldn't afford extra tutoring. That moment sparked an idea that would eventually land me as a finalist in AWS AIdeas 2025.

The Problem That Wouldn't Leave Me Alone

In Ethiopia, quality education is a luxury. Most students can't access personalized tutoring, and even fewer can learn in their native language. While building web apps for clients, I kept thinking about my sister and millions of students like her. The real kicker? Most educational AI tools require constant internet connectivity – something we definitely can't count on in rural Ethiopia.

Building Ivy: More Than Just Another Chatbot

I started Ivy as a weekend hackathon project, but it quickly became my obsession. The core challenge was creating an AI tutor that could:

Understand and respond in Amharic naturally
Work offline when internet is spotty
Actually engage students in conversation, not just answer questions

Here's the technical approach that made it work:

Voice-First Architecture

// Simplified voice processing pipeline
class VoiceProcessor {
  constructor() {
    this.speechRecognition = new webkitSpeechRecognition();
    this.speechSynthesis = window.speechSynthesis;
    this.amharicModel = new AmharicNLPModel();
  }

  async processVoiceInput(audioBlob) {
    const transcript = await this.transcribeAmharic(audioBlob);
    const response = await this.amharicModel.generateResponse(transcript);
    return this.synthesizeAmharicSpeech(response);
  }
}

The breakthrough came when I realized students learn better through conversation than Q&A. Instead of waiting for questions, Ivy proactively guides discussions, asks follow-ups, and adapts to each student's pace.

Offline-First Design

The real technical challenge was making AI work without constant cloud connectivity. I implemented a hybrid approach:

Core reasoning engine runs locally using optimized models
Knowledge base is cached and synced when online
Voice processing happens on-device for privacy and speed

This meant students in remote areas could still get quality tutoring even when their internet cut out mid-lesson.

From Side Project to Global Recognition

What started as helping my sister became something bigger. I spent nights after my day job training Amharic language models, optimizing for mobile devices with limited processing power, and testing with students across Addis Ababa.

The user feedback was incredible. Students weren't just getting answers – they were having genuine learning conversations in their native language. Teachers started reaching out, asking how they could integrate Ivy into their classrooms.

The Lessons That Shaped Everything

Building Ivy taught me that the best tech solutions come from real problems, not cool technologies looking for applications. Here's what I learned:

Start with empathy, not algorithms: Understanding my users' daily reality was more valuable than any ML paper
Constraints breed creativity: Limited internet forced innovative offline solutions
Community feedback is gold: Ethiopian students shaped every feature decision

The AWS AIdeas competition validation feels surreal. Ivy is now a finalist competing globally, representing not just my work, but the potential of African innovation in AI.

What's Next

Whether Ivy wins or not, this journey proved that impactful AI doesn't require Silicon Valley resources – just genuine problems and persistent iteration. I'm continuing to expand Ivy's capabilities and exploring partnerships with Ethiopian schools.

If this resonates with you, I'd be incredibly grateful for your vote in the AWS AIdeas competition. Community voting determines the winner, and your support could help bring quality education to students across Ethiopia and beyond. Vote here – it takes just a minute but could change everything for students like my sister.

What problems in your community could you solve with code? Sometimes the best ideas are hiding in plain sight.

Building an AI Tutor for 40 Million Ethiopian Students Who Learn in Amharic

Natnael Getenew — Sat, 18 Apr 2026 00:13:54 +0000

When I tell people that 40 million Ethiopian students don't have access to quality tutoring, they're shocked. When I explain that most of them learn in Amharic—not English—the tech community suddenly goes quiet.

This is the reality I've been wrestling with as a developer in Addis Ababa. Ethiopia has one of the largest student populations in Africa, but educational resources are scarce, expensive, and almost exclusively in English. Meanwhile, most students think and learn in their native language.

The Language Barrier Nobody Talks About

Here's what blew my mind during my research: cognitive load theory shows that students learn 40% faster when taught in their native language. Yet every AI tutor I found was English-first, treating other languages as an afterthought.

I realized we needed something different—an AI that could naturally converse in Amharic, understand cultural context, and work offline (because internet connectivity is still a luxury for many).

Building Ivy: Technical Challenges I Didn't Expect

Creating Ivy, my AI tutoring platform, taught me that voice AI in low-resource languages is hard. Here are the biggest technical hurdles:

1. Amharic Speech Recognition

Most speech-to-text APIs barely support Amharic. I had to:

Fine-tune existing models with local speech patterns
Handle code-switching (when students mix Amharic and English mid-sentence)
Account for regional accents and dialects

2. Offline-First Architecture

With unreliable internet, Ivy needed to work offline. My solution:

// Simplified offline sync strategy
const syncQueue = {
  pending: [],
  sync: async () => {
    if (navigator.onLine) {
      await Promise.all(pending.map(syncItem));
      pending = [];
    }
  }
};

3. Cultural Context in AI Responses

Generic AI responses don't work. Ethiopian students relate better to examples using familiar contexts—like calculating the area of an injera (traditional bread) rather than a pizza.

What I Learned About Voice AI for Education

Voice changes everything. Text-based tutors feel formal and intimidating. Voice makes learning conversational and natural. Students ask follow-up questions they'd never type.

Proactive AI works better than reactive. Instead of waiting for questions, Ivy checks in: "You seem stuck on this problem. Want me to break it down differently?"

Local deployment matters. Running inference locally reduces latency and works offline, but model optimization becomes crucial.

The Numbers That Keep Me Going

40 million students in Ethiopia's education system
70% lack access to quality tutoring
Average tutor costs $50/month (many families earn $100/month)
Ivy costs less than $5/month

Real Impact, Real Feedback

Beta testing revealed something beautiful: students started asking Ivy questions they were too shy to ask human teachers. The AI removed the fear of judgment that often blocks learning.

One student told me, "Finally, someone who speaks my language and doesn't make me feel stupid for not knowing something."

What's Next

Ivy is now a finalist in the AWS AIdeas 2025 global competition. The winner is decided by community voting, and this could be the push needed to scale Ivy across Ethiopia and beyond.

Building for underserved markets taught me that the most impactful tech often comes from solving problems the global tech community doesn't see. We don't need another English-first AI tool—we need AI that meets people where they are.

Want to help 40 million students get better education? Vote for Ivy in the AWS AIdeas competition. Every vote brings us closer to making quality education accessible in every language.

What challenges have you faced building for underserved markets? I'd love to hear your experiences in the comments.

Why Building AI for Non-English Speakers is Harder Than You Think (And How I Did It Anyway)

Natnael Getenew — Fri, 17 Apr 2026 04:37:53 +0000

Over 70% of the world doesn't speak English fluently, yet most AI applications are built with English as the default. When I started building Ivy, an AI tutor for Ethiopian students, I quickly discovered why this gap exists—and it's not just about translation.

The Real Challenge Isn't Translation

My first naive approach was simple: build in English, then translate. Wrong move. Here's what I learned:

Cultural Context Matters More Than Grammar
Ethiopian students don't just need Amharic words—they need culturally relevant examples. When teaching math, mentioning "buying injera at the market" resonates way more than "buying apples at the store."

Voice AI Gets Tricky with Tonal Languages
Amharic has unique phonetic patterns that standard speech recognition models struggle with. I had to fine-tune my voice processing pipeline specifically for Amharic pronunciation and intonation patterns.

Technical Hurdles I Hit (And Solved)

1. Limited Training Data

Unlike English, there's not much Amharic educational content online to train on. My solution:

# Custom data augmentation for low-resource languages
def augment_amharic_dataset(original_text):
    # Synthetic data generation using cultural context
    augmented_samples = []

    # Replace generic examples with local ones
    cultural_replacements = {
        "pizza": "injera",
        "dollars": "birr",
        "subway": "blue donkey taxi"
    }

    return augmented_samples

2. Offline Capability

Internet connectivity in Ethiopia can be unreliable. I built Ivy to work offline by:

Pre-loading essential models locally
Using efficient model compression techniques
Implementing smart caching for frequently accessed content

3. Code-Switching Handling

Students often mix Amharic with English mid-conversation. I had to build a detection system that could seamlessly handle both languages without breaking the conversation flow.

What I Wish I Knew Before Starting

Start with the Community, Not the Code
I spent months perfecting the AI before talking to actual students. Big mistake. The feedback I got after building an MVP changed everything about my approach.

Voice-First Changes Everything
Text-based tutoring feels formal and intimidating to many Ethiopian students. But voice conversations? That's natural. It's how they learn from elders, how they discuss problems with friends.

Performance Optimization is Critical
When your target users have older Android phones and limited data, every millisecond and megabyte matters. I learned to obsess over model size and response times in ways I never had to with English-first applications.

The Technical Stack That Worked

Speech Processing: Custom fine-tuned models for Amharic
NLP: Multilingual transformers with cultural context injection
Backend: Lightweight Python APIs optimized for edge deployment
Mobile: React Native with offline-first architecture

Beyond the Code

Building for non-English speakers taught me that great AI isn't just about algorithms—it's about understanding your users' world. The most elegant code means nothing if it doesn't fit into someone's daily life and cultural context.

The response from Ethiopian students has been incredible. Seeing kids who struggled with traditional learning methods suddenly engage through natural conversation in their native language—that's what makes the technical challenges worth it.

What's Next

Ivy is currently a finalist in the AWS AIdeas 2025 global competition, where community voting helps decide the winner. If you found this technical journey interesting, I'd love your support: Vote for Ivy here.

Building AI for underrepresented languages isn't just a technical challenge—it's an opportunity to democratize access to quality education. The world needs more developers thinking beyond English-first solutions.

Have you built applications for non-English speakers? What challenges did you face? Drop your experiences in the comments—I'd love to learn from your journey too.

Building an AI Tutor for Ethiopia: What I Learned Competing in AWS AIdeas 2025

Natnael Getenew — Fri, 17 Apr 2026 04:01:56 +0000

Over 70% of Ethiopian students don't have reliable internet access. Yet here I was, building an AI tutor that needed to work for them too.

When I started building Ivy, my AI tutor for Ethiopian students, I thought the hard part would be the voice recognition in Amharic. Turns out, that was just the beginning of a journey that taught me more about building resilient AI systems than any tutorial ever could.

The Offline Challenge That Changed Everything

My first prototype was a typical web app – sleek, fast, and completely useless when the internet cut out. In Ethiopia, power outages and connectivity issues are daily realities. I realized I wasn't just building an AI tutor; I was building for infrastructure constraints that most developers never consider.

This led me to explore edge AI deployment in ways I never expected. Instead of relying solely on cloud APIs, I had to:

Implement local speech-to-text using lightweight models
Cache conversation context aggressively
Build a hybrid system that gracefully degrades when offline

// Simplified offline detection and fallback
class AITutorService {
  async processQuery(audioBlob, context) {
    if (navigator.onLine && this.cloudAvailable) {
      return await this.processWithCloud(audioBlob, context);
    }

    // Fallback to local processing
    return await this.processLocally(audioBlob, context);
  }

  async processLocally(audioBlob, context) {
    // Use cached models and pre-computed responses
    const transcript = await this.localSTT.transcribe(audioBlob);
    return this.localLLM.respond(transcript, context);
  }
}

Voice AI in Low-Resource Languages

Building voice interfaces for Amharic taught me that "just use OpenAI's API" isn't always the answer. Amharic has unique phonetic patterns, and most commercial STT services perform poorly with it.

I ended up training custom models using:

Mozilla DeepSpeech as a base
Crowdsourced audio from Ethiopian university students
Data augmentation techniques to stretch limited training data

The breakthrough came when I realized I didn't need perfect transcription – I needed good enough recognition for educational contexts. By constraining the vocabulary to academic terms and common student questions, accuracy jumped from 60% to 85%.

Scaling on a Shoestring Budget

Running AI models isn't cheap, especially when you're targeting users who can't pay premium prices. I learned to optimize ruthlessly:

Model Compression: Used quantization to reduce model sizes by 75% with minimal accuracy loss.

Smart Caching: Implemented semantic caching for common questions. If a student asks "What is photosynthesis?" in slightly different ways, serve the cached response.

Usage Patterns: Ethiopian students often study in groups. Building collaborative features reduced per-user compute costs while improving the learning experience.

The Competition Experience

Entering AWS AIdeas 2025 forced me to articulate not just what Ivy does, but why it matters. The competition pushed me to think bigger – how could this solution work beyond Ethiopia? What technical patterns could other developers use for similar challenges?

The feedback from AWS experts helped me realize that building for constraints often leads to more innovative solutions. Ivy's offline capabilities and efficiency optimizations make it suitable for any region with infrastructure challenges.

What's Next

Being selected as a finalist in AWS AIdeas 2025 has been incredible validation, but the real test is impact. I'm already seeing students in rural areas use Ivy to practice English pronunciation and get help with math problems – things that weren't possible before.

The competition has also opened doors to collaborate with other developers facing similar challenges in different contexts. There's something powerful about building technology that works for everyone, not just those with perfect connectivity.

If you're interested in supporting innovative AI solutions for education, I'd be grateful for your vote in the AWS AIdeas competition: https://builder.aws.com/content/3CQJ9SY2gNvSZKWd3tEq8ny7kSr/aideas-finalist-ivy-the-worlds-first-offline-capable-proactive-ai-tutoring-agent

Community voting plays a huge role in determining the winner, and every vote helps bring AI education tools to students who need them most.

One sentence in VS Code. My entire Notion workspace becomes a live interactive briefing and the AI handles the rest.

Natnael Getenew — Sat, 28 Mar 2026 08:08:36 +0000

This is a submission for the Notion MCP Challenge

I maintain an open source AI agent SDK. I'm building a startup. I do both alone, from Addis Ababa, at 24, no team.

Every morning I open Notion and spend 15 minutes manually figuring out what's actually on fire. What's overdue. What's tied to which goal. I piece it together across five databases, hold it in working memory, then try to work.

That 15 minutes compounds. Every day. It's not a productivity problem - it's a tax on building alone.

People who have a chief of staff don't pay that tax. I can't afford one. So I built one.

The Thing Nobody Had Done Before

Before this, "AI + Notion" meant: AI reads your data and writes a text summary back at you. You still had to act on it yourself. You still had to go to Notion and change things.

Chief of Staff breaks both of those constraints at once.

First: the UI lives inside the chat. When you ask for your briefing, a full rendered dashboard appears inside the conversation — task rows, progress bars, overdue indicators, action buttons. It's not a screenshot. It's not a link. It's a live React app running inside an iframe inside VS Code Copilot or Claude. You can interact with it. Check off a task and it's gone from the list and marked done in Notion in the same click.

Checking a checkbox on a visual task — inside VS Code, without opening Notion, without leaving your editor — that had never been built before.

Second: the agent doesn't hand you a report. It executes. The action buttons in the dashboard don't navigate you somewhere. They tell the AI to go do the work. The AI calls the right MCP tool, reasons through the changes, and writes them back to Notion. You direct. It executes. The loop closes inside a single conversation.

This is what a chief of staff actually does. Not informing you. Acting on your behalf.

What I Built

Chief of Staff is an MCP App that reads your Notion workspace every morning and briefs you — then handles the work you tell it to.

You type: "Give me my morning briefing."

A live, interactive dashboard renders directly inside VS Code Copilot Chat — or Claude. Not a link to an external tool. Not a text summary. A real UI with real data, living inside your editor. You can click a checkbox and the task is marked done in Notion. You can click a button and the agent reschedules your entire overdue pile. You never leave your editor.

That's new. Nobody had shipped this before.

⚡ Plan my week → the AI generates a task breakdown and creates every task directly in your Notion database
📅 Reschedule overdue tasks → the AI looks at everything overdue, picks sensible new dates based on priority, patches them all in Notion. The guilt pile disappears.
📋 Write weekly review → the AI pulls your completed tasks, synthesizes what happened, writes a full structured page into your workspace
🎯 Break down stalled goal → the AI takes a goal sitting at 5% and creates 4-6 concrete sub-tasks with due dates in Notion

The briefing is the interface. Notion is where the work lands.

GitHub: https://github.com/Garinmckayl/chief-of-staff

How I Used Notion MCP

Notion MCP is the reason the write path exists. Without it I'd need custom integrations per action. With it, the AI can read and write across the entire workspace through one protocol, and every agent tool is just a description of what needs to happen.

The 8 MCP tools

Tool	What it does
`chief_of_staff_briefing`	Renders the live interactive dashboard as an MCP App
`get_notion_briefing_data`	Reads your workspace — discovers databases dynamically, no hardcoded IDs
`complete_notion_task`	Marks a task done — detects whether Status is a select, native status, or checkbox
`create_notion_tasks`	Writes an AI-generated task plan straight into your Notion database
`reschedule_overdue_tasks`	Updates due dates — the AI picks the dates and explains each one
`write_weekly_review`	Creates a structured weekly review page in your workspace
`break_down_goal`	Generates sub-tasks for a stalled goal and creates them in Notion
`get_completed_tasks`	Fetches done tasks from the past N days for the weekly review

The generative UI layer

The interactive dashboard is a live React app that renders inside the chat - compiled to a single self-contained HTML string and returned as a tool response. When the AI calls chief_of_staff_briefing, the entire UI materialises: task rows, progress bars, overdue indicators, action buttons. All driven by your real Notion data.

The component catalog defines everything the AI can compose:

FocusCard      — the single most important thing right now
TaskList       — grouped task rows with heading and count
TaskRow        — individual task with completion checkbox that writes to Notion
GoalProgress   — progress bar with live percentage
InsightBadge   — win / tip / warning / pattern pill
AgentAction    — the button that triggers real Notion writes
SectionHeader  — section divider

The AI fills this catalog from your actual Notion data. Every task row is real. Every progress bar reflects a real goal. The AgentAction component fires an event that the AI receives and routes to the right MCP tool. Visual layer and execution layer are the same system.

The agentic loop

The dashboard and the agent tools are two halves of the same system. The briefing shows the situation. The AgentAction buttons close the loop.

When you click "Reschedule overdue tasks," the AI gets a run_agent event, calls get_notion_briefing_data to see what's actually overdue, reasons about dates based on priority, and calls reschedule_overdue_tasks with the full update list. Notion gets patched. You touched nothing.

mcpServer.tool(
  "reschedule_overdue_tasks",
  `Reschedule overdue tasks by updating their due dates in Notion.
  First call get_notion_briefing_data to get current overdue tasks.
  Decide sensible new due dates based on priority and today's date.
  Spread them out — don't dump everything on one day.`,
  {
    updates: z.array(z.object({
      taskId: z.string(),
      newDueDate: z.string(),
      reason: z.string(),
    })),
  },
  async ({ updates }) => {
    const results = await rescheduleTasks(updates);
    return { content: [{ type: "text", text: JSON.stringify(results) }] };
  }
);

The reason field is intentional. The AI isn't just moving dates — it's explaining why. You can see the reasoning in the tool call output. That's what makes it feel like delegation rather than automation.

Dynamic workspace discovery

No hardcoded database IDs. The system discovers your workspace by reading property shapes — it inspects what fields each database has, not what it's named. Databases with progress or percent fields are classified as goal trackers. Databases with status or due date fields are classified as task lists. This means it adapts to however you've structured your workspace — different column names, different layouts, different numbers of databases.

// Goals have progress fields — exclude them from task DBs
if (hasProgress) {
  goalDbs.push({ id: db.id, name: title });
} else if (hasStatus || hasDue) {
  taskDbs.push({ id: db.id, name: title });
}

Works on any Notion workspace structure, out of the box.

The parts that were actually hard

completeTask silently did nothing for weeks. It was calling the Notion native status type, but most databases use a select field for Status. The silent fallback was to archive the page instead. Fixed it by reading the page schema first and detecting the actual property type before writing.

Goal databases kept appearing as task databases. Any database with a Status column and a date field got classified as tasks. My Goals DB has both. Fixed by checking for a progress/percent field first — if it exists, it's a goal DB.

Neither was hard to fix. Both would silently break the demo if I hadn't caught them.

Technical Stack

Layer	What
MCP server	`@modelcontextprotocol/sdk` — stdio + StreamableHTTP transports
Generative UI	React app compiled to a single HTML string, served as a tool response, rendered live inside the chat
Notion writes	Direct REST API with dynamic schema detection
Bundler	Vite + `vite-plugin-singlefile` (entire React app as one inlined HTML string)
Runtime	Node.js + tsx

Run it in 60 seconds with GitHub Codespaces — the repo includes devcontainer.json with everything pre-configured, port 3333 forwarded, NOTION_API_KEY as the only required secret.

git clone https://github.com/Garinmckayl/chief-of-staff
cd chief-of-staff && npm install && npm run build
NOTION_API_KEY=your_key npm run start:stdio

Why This Matters

Before Chief of Staff, "AI + your data" meant a smarter search or a better summary. You still had to act on the output yourself. The AI was a reader. You were still the writer.

Chief of Staff makes the AI the writer too. It reads your workspace, shows you the situation visually, and when you point it at a problem — it fixes it. All in Notion. None of it requiring you to open a single Notion page.

I built this because I needed it. I'm a solo founder in Addis Ababa, maintaining open source infrastructure, building a startup, without a team, in a city where many of the tools the rest of the world assumes you have aren't available to you. Claude Desktop doesn't work here. I demo this in VS Code Copilot because that's what I actually have access to.

That constraint shaped everything. It works with what you have. One workspace, one API key, one command.

Three weeks ago, building an interactive visual app that lives inside VS Code wasn't possible. Now it is. And the first thing I built with it was a chief of staff — because that's what I needed most.

This isn't productivity software. It's what happens when the person who builds infrastructure finally gets some infrastructure of their own.

Built for the Notion MCP Challenge
GitHub: https://github.com/Garinmckayl/chief-of-staff

Arlo - I Built an AI Companion That Gives Blind Users the Same 3-Second Superpower Sighted People Have

Natnael Getenew — Sun, 22 Mar 2026 12:16:40 +0000

This is a submission for the Notion MCP Challenge

I'm 24. I dropped out. I'm building an AI startup from Addis Ababa, Ethiopia.

I built Arlo in 9 days because I kept thinking about a specific number: 253 million people with vision loss navigate the web the same way every single time - from zero, with no memory of what helped them before. Every visit. Every site. From scratch.

Notion MCP is what finally made a real solution possible.

The Problem Nobody Talks About

A sighted person lands on a flight booking page and within 3 seconds they know: there's a search bar at the top, filters on the left, results in the middle. Three seconds.

A blind user with a screen reader starts from the top and listens. Every navigation link. Every cookie banner. Every decorative image. Every sponsored result. On a site like Kayak, that's often 200+ elements before a single fare. And every visit starts from zero - the screen reader has no memory of what helped last time.

I built Arlo because that's not good enough.

What I Built

Arlo is an AI companion that gives visually impaired users the same 3-second superpower sighted people have.

You tell Arlo what you want to do. Arlo reads the entire page and tells you exactly what matters - in natural spoken language. Like a trusted friend who can see the screen.

But here's what makes Arlo different from every other accessibility tool:

Arlo remembers you. And that memory lives in Notion.

Every visit, Arlo learns. It learns that you always pick the cheapest option. It learns that on Amazon you skip sponsored results. It learns that the SSA website has a confusing dropdown on step 3 that catches people off guard. All of that gets saved to your personal Notion database — structured, readable, yours to own and edit.

The next visit, Arlo opens with: "I remember you've been here before. Last time you were looking for Delta flights and picked the 7am option — want me to head straight there?"

That's not a screen reader. That's a companion.

Video Demo

Live: https://arlo.arcumet.com

Try it yourself: paste any URL, speak or type your goal, and Arlo guides you.

The Flow

1. You say what you want
Type it or speak it. Arlo uses GLM-ASR for voice — accurate across accents.

2. Arlo reads the entire page
Not static HTML parsing — GLM Web Reader fully renders the page including JavaScript. React apps, SPAs, Google Flights, Twitter — all work.

3. Notion memory is checked
Before analyzing, Arlo queries your Notion database: "What do I know about this domain? What has this user done here before?" That context shapes everything.

4. Arlo speaks
Not a list of elements. Arlo says: "You're on Amazon search results. Based on what I remember, you prefer under $100 and skip sponsored results. The first non-sponsored option is the Soundcore Q20i at $59.99."

After the visit, new learnings are written back to Notion via MCP. The loop closes.

How I Used Notion MCP

Notion isn't a feature in Arlo. Notion is Arlo's brain.

Without Notion, Arlo is just another AI tool that forgets you the moment you close the tab. With Notion MCP, Arlo becomes something that grows with you — a companion that gets better every single time you use it.

The MCP integration loop

User visits page
       ↓
Arlo queries Notion MCP: "What do I know about this domain?"
       ↓
GLM-4.6 analyzes page + goal + memory context
       ↓
Arlo speaks guidance (Hume Octave ultra-realistic TTS)
       ↓
New insights written back to Notion via MCP
       ↓
Next visit: Arlo already knows you

Every memory entry is a full rich Notion page — not just a database row. Heading blocks, bullet context, callout explaining what was learned, linked back to the source page. The user can open Notion and read exactly what Arlo knows about them, edit it, or delete it. Transparent, human-readable memory they own.

The Notion MCP server integration

Arlo uses @notionhq/notion-mcp-server with stdio transport for all writes — the same MCP protocol that Claude Desktop, Cursor, and other AI tools use:

// Spawn the Notion MCP server as a subprocess
const transport = new StdioClientTransport({
  command: "node",
  args: [MCP_SERVER_BIN, "--transport", "stdio"],
  env: { NOTION_TOKEN: process.env.NOTION_API_KEY },
});

const client = new Client({ name: "arlo", version: "1.0.0" }, { capabilities: {} });
await client.connect(transport);

// Write memory via MCP tool call — not REST API
await client.callTool({ name: "API-post-page", arguments: { ... } });

Show me the code

GitHub: https://github.com/Garinmckayl/arlo

Technical Stack

Layer	What
Page reading	GLM Web Reader API — full JS rendering
Intelligence	GLM-4.6 with thinking mode
Vision	GLM-4.6V for screenshot analysis
Voice input	GLM-ASR-2512
Voice output	Hume Octave TTS — ultra-realistic
Memory writes	Notion MCP (`@notionhq/notion-mcp-server` stdio)
Memory reads	Notion REST API (zero-latency for live context)
Framework	Next.js 16, deployed on Vercel

Why This Matters

Most AI accessibility tools are built by people who don't need them, for a problem they've read about rather than felt. They work on clean demo sites and fall apart on the chaotic, JS-heavy, dark-pattern-filled reality of the actual web.

Arlo is built around the real failure mode: the web doesn't remember you, and that costs blind users enormous time and cognitive load on every single visit.

The Notion memory layer isn't a clever integration for the sake of a hackathon. It's the answer to a real question: if this tool is going to be useful long-term, it needs to get better with use, and the user needs to be able to trust and control what it knows about them.

Notion is the right answer. It's human-readable. It's editable. It's already where people organize their lives. And with MCP, it becomes a living brain that any AI tool can read from and write to.

Built in 9 days · Live at https://arlo.arcumet.com · GitHub

I Built a Personal AI Computer With Gemini - Here's How

Natnael Getenew — Thu, 12 Mar 2026 12:54:12 +0000

This article was created for the purposes of entering the Gemini Live Agent Challenge hackathon. #GeminiLiveAgentChallenge

The Problem Nobody Has Solved

306,000 people starred Open Claw on GitHub. They all want the same thing: a personal AI that actually does things. Sends emails. Manages calendars. Runs code. Browses the web. Learns new skills.

But every solution looks the same: clone the repo, install Docker, configure API keys, run terminal commands, manage a cloud bill. The technology is amazing. The accessibility is terrible.

8 billion people want a personal AI computer. 99% of them will never run a Docker container.

So I built Elora.

What Elora Is

Elora is not a chatbot. She's a personal AI computer that lives on your phone.

She has her own sandbox (a persistent cloud VM where she installs packages, runs code, and saves files - isolated per user). She has her own skill system (she can search for skills, install them, or write new ones from scratch). And she has a security layer that protects everything she does.

You download the app and talk to her. That's it. No setup. No API keys. No Docker.

Elora Live Voice Architecture

Elora Wake Word

The Tech Stack

Layer	Technology
Mobile	Expo / React Native (TypeScript)
Voice	Gemini Live API (real-time bidirectional audio)
Agent	Google ADK (multi-agent orchestration)
LLM	Gemini 2.0 Flash / 2.5 Flash
Browser	Playwright + Gemini 2.5 Flash (computer use)
Code Sandbox	E2B (per-user persistent VMs)
Skills	Custom skill engine (search, install, create, execute)
Security	Agntor trust protocol
Memory	MemU + Firestore + text-embedding-004
Backend	FastAPI on Google Cloud Run
IaC	Terraform + GitHub Actions CI/CD

Let me walk through how I built the pieces that matter.

1. Voice That Feels Alive - Gemini Live API

The Gemini Live API is what makes Elora feel real. It's full duplex audio - she talks while you talk, you can interrupt her mid-sentence, and she handles it naturally.

Here's the architecture for voice:

Phone (mic) → PCM audio chunks via WebSocket → Cloud Run
  → Gemini Live API session (bidirectional)
  → Audio response chunks → WebSocket → Phone (speaker)

The mobile app maintains three simultaneous WebSocket connections:

Text chat - ADK agent with full tool calling
Live audio - Gemini Live API with real-time audio streaming
Wake word - Always-on "Hey Elora" detection

The wake word detector is its own Gemini Live session configured to only respond with "WAKE" when it hears the trigger phrase. Minimal tokens, always listening.

The hardest part: Gemini Live API doesn't support ADK's tool-calling protocol natively. So I built a parallel system - manual JSON schemas for every tool declaration, a dispatch function that maps tool names to the same Python functions the ADK agent uses, and a response handler that streams tool results back into the Live session. Every tool works in both text mode (ADK) and voice mode (Live API).

2. Vision - She Sees Your World

During a live call, Elora watches through your camera. The mobile app captures frames and sends them as base64 JPEG over the WebSocket. On the backend, a proactive vision loop runs every 3 seconds:

# Simplified proactive vision logic
if camera_active and user_quiet_for_8s and last_proactive_25s_ago:
    frame = latest_camera_frame
    faces = await recognize_faces(frame, user_id)
    prompt = f"[VISION CHECK] You see: {faces}. Comment if relevant."
    session.send(prompt + frame)
    # If Elora responds with <silent>, swallow the response

She doesn't just respond when asked - she speaks up when she sees something worth mentioning. Point the camera at a friend she's seen before, and she'll say their name. That's face recognition using Gemini Vision with two-pass comparison against stored reference images in Cloud Storage.

3. The Skill System - Why Elora Is a Computer, Not a Chatbot

This is the feature I'm most proud of. Every AI assistant has a fixed set of tools. Elora can learn new ones.

The skill system works in four modes:

Search: Query the skill registry (bundled + community) by keyword.

Install: Download a skill definition (YAML metadata + Python code) into the user's Firestore profile and deploy it to their sandbox.

Execute: Load the skill code, fill in template parameters, and run it in the user's E2B sandbox. Real code, real output.

Create: This is the magic. Tell Elora "create a skill that checks if a website is up" and she:

Writes the Python code
Creates a YAML skill definition with parameters
Tests the code in your sandbox with a dry run
Validates the output
Saves it permanently to your library

The skill you asked for now exists forever. You can run it tomorrow, next week, next year.

# Bundled skills ship with Elora
BUNDLED_SKILLS = {
    "weather": {
        "name": "weather",
        "description": "Get current weather for any city",
        "code": "import requests\nurl = f'https://api.open-meteo.com/v1/forecast?latitude={lat}&longitude={lon}&current_weather=true'\n..."
    },
    "crypto_prices": { ... },
    "hackernews": { ... },
    "exchange_rates": { ... },
    "wikipedia": { ... },
    "rss_reader": { ... },
}

Six skills ship bundled. Users can create unlimited custom ones. And there's a community registry where you can publish skills for others to use.

This is what transforms Elora from "assistant" to "computer." A computer isn't defined by what it ships with - it's defined by what you can make it do.

4. Per-User Sandbox - Your Computer in the Cloud

Every Elora user gets their own isolated cloud VM via E2B. This isn't shared compute - it's YOUR machine.

def get_or_create_sandbox(user_id: str):
    # Check in-memory cache
    if user_id in _active_sandboxes:
        return _active_sandboxes[user_id]

    # Check Firestore for paused sandbox ID
    doc = _get_sandbox_doc(user_id).get()
    if doc.exists:
        sandbox_id = doc.to_dict().get("sandbox_id")
        # Reconnect to existing sandbox
        sandbox = Sandbox.connect(sandbox_id)
    else:
        # Create new sandbox with pre-installed packages
        sandbox = Sandbox(timeout=3600, metadata={"user_id": user_id})
        sandbox.commands.run("pip install requests beautifulsoup4 feedparser pyyaml")
        sandbox.commands.run("mkdir -p /home/user/skills /home/user/workspace /home/user/data")
        # Persist sandbox ID
        _get_sandbox_doc(user_id).set({"sandbox_id": sandbox.sandbox_id})

    _active_sandboxes[user_id] = sandbox
    return sandbox

Sandboxes auto-pause when idle and reconnect when needed. Packages you install persist. Files you create persist. The sandbox ID is stored in Firestore so it survives server restarts.

When Elora runs code for you - whether it's a skill, a script you asked for, or a data analysis
it runs in YOUR sandbox. Nobody else can see it or touch it.

5. Security - The Agntor Trust Protocol

When your AI agent has access to your email, calendar, files, and code execution, security isn't optional.

The Agntor trust protocol runs as middleware on every incoming message:

Prompt injection guard - 12 regex patterns + 3 heuristic checks + structural analysis. Catches "ignore previous instructions" and its 50 variants.
PII/secret redaction - Detects and masks API keys, tokens, credit card numbers, and SSNs before they reach the model.
Tool guardrails - Blocklist (shell.exec, eval) and confirmation list (send_email, delete_file). Dangerous tools are blocked. Sensitive tools require explicit confirmation.
SSRF protection - Validates all URLs against private IP ranges with DNS resolution. Prevents the model from being tricked into accessing internal services.
Agent identity - A verifiable identity endpoint that exposes Elora's capabilities and security posture.

$ curl https://elora-backend-453139277365.us-central1.run.app/agent/identity
{
  "agent_name": "Elora",
  "version": "0.5.0",
  "security": {
    "prompt_guard": true,
    "pii_redaction": true,
    "tool_guardrails": true,
    "ssrf_protection": true
  }
}

The entire security layer is pure Python - no external dependencies. It's fast enough to run on every message without noticeable latency.

6. Multi-Agent Architecture - Google ADK

Elora uses Google's Agent Development Kit (ADK) with a hierarchical multi-agent architecture:

elora_root (orchestrator)
├── web_researcher    → web_search + fetch_webpage
├── browser_worker    → Playwright + Gemini computer-use
├── email_calendar    → Gmail + Google Calendar (full CRUD)
├── file_memory       → Cloud Storage + Firestore memory
└── research_loop     → LoopAgent with self-verification

The root agent decides which sub-agent to delegate to based on the user's intent. "Send an email" goes to email_calendar. "What's on Hacker News" goes to browser_worker. "Remember that I prefer morning meetings" goes to file_memory.

ADK's constraint of one parent per agent forced clean separation of concerns. Each sub-agent has exactly the tools it needs and nothing more.

7. 40+ Real Tools

These aren't mock tools. They execute real actions:

Gmail - Send, read, archive, trash, label, batch manage
Google Calendar - Create, update, delete, list, search
Browser - Playwright opens real pages, takes screenshots, Gemini reasons about what it sees
Code execution - Python and JavaScript in your personal sandbox
SMS - Twilio (with deep-link fallback)
Google Slides & Docs - Programmatic creation with shareable links
Face recognition - Two-pass Gemini Vision comparison against stored references
File management - Upload, read, list, delete in per-user Cloud Storage
Reminders - Natural language time parsing, push notification delivery
People memory - Names, relationships, birthdays, contact info, appearance
Proactive engine - Meeting alerts, birthday nudges, stale contact check-ins

8. Memory - She Remembers Everything

Elora has a 3-layer memory system:

Layer 1: Raw facts. After every conversation, a background task extracts key facts and stores them as vector embeddings (text-embedding-004) in Firestore. Semantic search retrieves relevant memories on every new conversation.

Layer 2: Compacted profile. Periodically, Gemini Flash merges and deduplicates raw facts into a structured user profile - preferences, relationships, work info, goals.

Layer 3: Session summaries. After every call, a summary is generated. The last 3 summaries are injected into the next session for continuity.

This is powered by MemU, which achieves 92% accuracy on the Locomo memory benchmark at 10x lower always-on cost compared to traditional RAG approaches.

Deployment

The entire backend deploys to Google Cloud Run with a single git push:

GitHub Actions builds the Docker image
Pushes to Artifact Registry
Deploys to Cloud Run with all environment variables
Creates Firestore indexes

Infrastructure is managed with Terraform:

resource "google_cloud_run_service" "elora_backend" {
  name     = "elora-backend"
  location = "us-central1"

  template {
    spec {
      containers {
        image = "us-central1-docker.pkg.dev/${var.project_id}/elora/backend:latest"
        resources {
          limits = { cpu = "2", memory = "2Gi" }
        }
      }
      timeout_seconds = 3600  # Long-running WebSocket connections
    }
  }
}

40+ Cloud Run revisions tell the development story. The backend has been continuously deployed and iterated throughout the build.

What I Learned

The gap between "chatbot" and "computer" is isolation, persistence, and extensibility. It's not about making the LLM smarter. It's about giving it a sandbox that persists, a skill system that grows, and security that you can trust. That's what makes it a computer.

Security can't be an afterthought. When your agent can read your email, send texts, and execute code, prompt injection isn't theoretical - it's an attack vector. Build the guard first.

ADK multi-agent is production-ready. The one-parent-per-agent constraint feels limiting at first, but it forces clean architecture. Each agent has exactly the tools and context it needs.

Try It

The backend is live:

https://elora-backend-453139277365.us-central1.run.app

The code is open:

https://github.com/Garinmckayl/elora

To run the mobile app:

git clone https://github.com/Garinmckayl/elora.git
cd elora/app
npm install
npx expo start --tunnel

Scan the QR code with Expo Go. Talk to Elora.

Built by a solo developer in Addis Ababa, Ethiopia for the Gemini Live Agent Challenge. #GeminiLiveAgentChallenge

GitHub: github.com/Garinmckayl/elora

Ivy - Bringing LLMs to 35 Million offline students in Ethiopia

Natnael Getenew — Sun, 08 Mar 2026 07:08:28 +0000

Hi everyone,

I’m writing this from Addis Ababa. While the world is talking about the latest LLM cloud features, 35 million students in Ethiopia are being left behind because they simply don't have stable internet or the hardware to run "modern" education.

I’ve spent the last few months building Ivy a specialized, offline tutor designed to run on low-end Android devices with zero connectivity. it’s an architecture built on edge-inference and local language support (Amharic) so that a kid in a rural village has the same educational "co-pilot" as someone in London or New York.

I’m a solo founder, and I’m currently 95% of the way through a global AWS challenge to get this project the resources it needs to scale. I’ve reached 50 likes on my own, but I’m at a point where I need the support of the broader tech community to reach the Top 50 and secure the next round of funding/support.

If you believe that state of the art education should be a tool for all students not just those with a fiber connection I would be incredibly grateful for your support.

How you can help:

Click the link to my official AWS entry: https://builder.aws.com/content/39w2EpJsgvWLg1yI3DNXfdX24tt/aideas-ivy-the-worlds-first-offline-capable-proactive-ai-tutoring-agent

If you find the "Why" and the "How" compelling, please hit the "Like" button.

I’m happy to answer any questions about the technical hurdles of edge-inference or the reality of building tech in Ethiopia. Thank you for reading.