01 — The Problem
The average person trying to stay informed today must navigate dozens of sources, frequently encountering the same story rewritten three different ways before finding anything new. The fragmentation is exhausting — and the cure is often worse than the disease. Algorithmic feeds designed to keep you engaged tend to deepen filter bubbles, showing you content that confirms what you already believe rather than broadening your perspective.
ELMO was built to solve exactly this. Rather than adding yet another news feed, we built a platform that synthesizes — pulling from multiple sources, stripping out the redundancy, and letting users control how deep they want to go on any given topic.
Core Goal
Aggregate news without repeating it — comprehensive coverage, zero redundancy
User Control
Choose between concise summaries or full deep-dives based on your time and interest
Source Transparency
Users can see and manage where their content comes from
Live Context
RAG pipeline brings in articles published within the last 24 hours, beyond any model's training data
02 — How It Works
ELMO's architecture is a deliberate layering of three systems: a cloud backend on AWS, a real-time news retrieval layer, and an AI generation pipeline driven by DeepSeek R1:14b. Each layer has a specific job, and they're connected by a custom RAG framework built by the AI Engineer on the team.
NewsAPI fetches up to 200 articles daily across user-selected categories. Google Search API fills gaps and surfaces breaking stories that NewsAPI's 24-hour delay misses.
NewsAPI often returns only a title and short description. JSDOM + Readability scrape the full article text from source URLs, giving the AI model something real to work with.
Article content is embedded into Pinecone's vector database, enabling semantic search — so when a user asks a question or expands an article, the system retrieves contextually relevant material rather than keyword matches.
DeepSeek R1:14b, hosted locally via Ollama and shared across the team through Ngrok tunneling, synthesizes retrieved content into summaries, full articles, or query-driven deep dives. Prompt engineering enforces accuracy and English-only output.
The frontend, built in Next.js + TypeScript, presents the output at whatever detail level the user has configured — from a quick summary to an expanded multi-source analysis. Everything is tied to a user account managed via AWS Cognito.
Measured in production
The 14-second AI generation Lambda runs in the background — users only experience the 3–4s summarization endpoints.
03 — Infrastructure
Rather than mixing cloud providers, we committed entirely to the AWS ecosystem — both to keep our architecture coherent and because the capstone gave us a chance to understand how these services actually fit together in a real application.
The connective tissue between our Next.js frontend and all AWS backend services. Handles deployment and resource management.
Serverless execution for AI article generation, daily bulk article population, API routing, and database operations. No always-on servers.
User authentication, account creation, and session management. Proved to be our steepest early learning curve — see the Challenges section.
Four tables: Users, Articles, SavedArticles, and LastViewedArticles. NoSQL made sense for the varied shape of article metadata.
Secure, authenticated exposure of Lambda functions to the frontend. Provides rate limiting and request logging.
Scheduled triggers for background tasks like the daily article curation Lambda — so 200 fresh articles are ready before users open the app each morning.
04 — What Broke
Every significant technical decision we made was driven by something breaking first. Click each challenge to read what actually happened and how we got through it.
05 — Decisions
We experimented with the idea of fine-tuning DeepSeek on news data, but the effort-to-gain ratio didn't make sense for a semester-long project. RAG gave us something more practically valuable: the ability to inject yesterday's news into every generation call, making the model's output genuinely current rather than frozen at a training cutoff.
We needed semantic search — the ability to find articles that are conceptually related to a user's query, not just keyword-matched. Pinecone's managed vector database let us skip the infrastructure complexity and focus on the embedding pipeline. It also made the article expansion feature possible: when a user expands an article, we retrieve semantically similar content from other sources and weave it in.
Running DeepSeek locally via Ollama meant we had full control over the model and zero per-token API costs during development. The tradeoff was hardware dependency — not everyone on the team had a machine that could run a 14B parameter model. Ngrok tunneling solved the access problem for development, and informed our future recommendation to containerize with AWS Fargate for production.
User research in the news space consistently shows that different contexts call for different depths: a commuter wants a headline and three sentences, a researcher wants the full story with sources. We built two one-tap AI calls — 'Simplify' and 'Expand' — on every article view, so users can go deeper or shallower without changing screens. The design philosophy was to anticipate user needs rather than require users to navigate to a settings page.
06 — The Team
ELMO was a capstone project for CS 4485 at UT Dallas, supervised by Professor Sridhar Alagar. Each team member owned a distinct layer of the system, with collaboration happening through weekly sprints, GitHub Projects, and daily Discord syncs.
07 — Takeaways
The single biggest improvement to our AI output came not from changing models, but from changing what we fed the model. When we started injecting real, recent articles from Google Search API into each generation call, the quality of output jumped noticeably. Relevance, accuracy, and coherence all improved — because the model had something concrete to synthesize rather than drawing purely from weights trained months ago.
Between NewsAPI's category limitations, AWS Cognito's evolving Amplify integration, and DeepSeek's behavior drift under certain prompt structures, we learned to treat documentation as a rough guide rather than a specification. The real knowledge came from running the code, reading error messages, and digging through GitHub issues from developers who hit the same walls.
Weekly sprint reviews made it hard to hide stalled work or ambiguous progress. Having to articulate what was done — and what wasn't — every seven days created a useful discipline. Tasks that seemed vague got scoped down. Features that seemed essential got deprioritized when the sprint showed we'd overcommitted.
We didn't conduct formal user studies, but we did constantly ask ourselves how we'd want to use the app. That question led us to cut several features we'd initially planned — category filters that were too granular, a recommendation engine we didn't have time to tune well — in favor of making the core reading experience fast and clean. The two-state article view (Simplify / Expand) came from this mindset.
08 — Future Work
Multi-language support
Expand beyond English-only output for global coverage
Opinion & bias detection
Surface when an article leans a particular direction, rather than leaving that judgment to the reader alone
Audio articles
Text-to-speech so the content is accessible while commuting or exercising
Mobile apps
iOS and Android native clients for the core read + explore experience
AI model optimization
Containerize with AWS Fargate; fine-tune DeepSeek with real user feedback signals
Automated testing
Replace manual Postman runs with a CI pipeline that validates generation quality on each deploy
Real-time alerts
EventBridge triggers for breaking news that bypasses the 24-hour daily batch
Reading analytics
Help users understand their own information diet: what topics, sources, and perspectives they're actually engaging with