Why I Built This
I wanted a practical system that could turn technical reading into something I could actually consume every day.
Like many engineers, I save far more articles than I ever finish. The problem is not access to information. It is the cost of converting raw reading material into something structured, relevant, and easy to consume during the day. My goal with Better ArchNews was to build a small but disciplined backend that could curate technical content, enrich it with LLM-generated intelligence, and expose it through a clean machine interface that other AI clients could use efficiently.
The final outcome is simple: I can generate a personalized podcast from technical articles, sync the resulting audio to my phone with Syncthing, and listen to it while I am out walking. Under the hood, however, the interesting part is not the audio. It is the architecture that makes the workflow reliable, cheap, and reusable.
The Core Design Goal
I did not want a one-off script. I wanted a system with a clear separation of concerns:
- ingestion and normalization of article sources
- semantic enrichment with an LLM
- vector storage and chunk-level retrieval
- a stable MCP interface for downstream AI clients
- a podcast pipeline that could operate as a separate concern
That design goal influenced almost every implementation decision.
The project is structured as a lightweight layered architecture with domain, application, and infrastructure boundaries. Core workflows depend on protocols rather than concrete implementations, which keeps orchestration logic easy to test and lets infrastructure details evolve without contaminating the service layer.
In practical terms, that means the crawler workflow, semantic processing, persistence layer, and MCP server are not tangled together. Each part has a clear responsibility, and each part can be reasoned about independently.
Architecture Over Convenience
The codebase is intentionally organized around a few focused modules.
The application layer orchestrates the end-to-end ingestion flow: discover sources, retrieve content, extract readable text, enrich it semantically, split it into chunks, embed it, and persist it.
The domain layer defines the entities and repository or service contracts. This is where the project states what an article is, what a chunk is, and what capabilities the system expects from storage and semantic processing.
The infrastructure layer implements the concrete details: PostgreSQL persistence with pgvector, content retrieval, LLM integration with Z.AI, and local embedding generation.
This is not architecture for architecture’s sake. It pays off in a few concrete ways:
- the orchestration flow is straightforward to test with fake repositories and mocked semantic services
- infrastructure changes remain localized
- the MCP server can reuse the same application services instead of duplicating business logic
- the podcast flow can remain adjacent to the rest of the system without being tightly coupled to the article ingestion model
That last point matters. The podcast generation capability is useful, but it should not dictate the shape of the core ingestion system. Treating it as a separate service keeps the boundaries healthy.
Where the Intelligence Actually Lives
The most valuable part of the project is not source acquisition. It is the semantic layer.
After content is retrieved and cleaned, the pipeline uses an LLM to generate:
- a concise summary
- a category
- a quality or relevance score
- tags
- a replacement title when the extracted one is poor
This turns a pile of raw article text into structured, queryable knowledge.
Important: The score is not just descriptive metadata. It also acts as a gate in the ingestion pipeline: if an article does not reach a defined threshold, it is discarded early so the system avoids unnecessary downstream work and wasted compute.
I deliberately used the most affordable Z.AI model in the ingestion stage because the task does not require a premium model. Summarization, categorization, title repair, and tagging benefit more from consistency and cost-efficiency than from frontier-level reasoning. The expensive model should be reserved for the point in the workflow where it creates visible user value.
That decision keeps ingestion cheap enough to run continuously without turning the system into an expensive hobby project.
Embeddings are generated locally on CPU and stored in PostgreSQL. Chunk-level embeddings are especially important because they let retrieval operate on semantically meaningful fragments instead of whole documents. That improves recall and makes downstream use more precise.
Why MCP Matters Here
One of the most useful design decisions in this project was exposing the curated content through an MCP server.
This is not just a convenience layer. It changes the economics of the whole workflow.
Instead of pushing large amounts of article text into a chat session up front, the MCP server exposes focused tools for retrieving ranked article candidates and then loading full article bodies only when needed. In other words, the client can do retrieval incrementally.
That matters for token efficiency.
When I use ChatGPT as the client, the interface itself can decide which sources to fetch through MCP tools, use that retrieved content as grounded context, generate the podcast dialogue from the selected material, and then send the resulting script back into the system so audio generation can start. By deliberately offloading the script generation to the ChatGPT client after retrieval, this token-intensive phase becomes completely free, avoiding the high API costs of generating long-form dialogue on the backend.
This has a few benefits:
- fewer unnecessary tokens are spent on irrelevant source material
- the retrieval step is explicit and inspectable
- the article corpus remains in the backend instead of being repeatedly copied into prompts
- the system behaves more like a proper RAG pipeline and less like a giant ad hoc context dump
That is the part I find especially compelling. MCP gives a clean boundary between a durable knowledge backend and an interactive AI client. The client handles synthesis. The backend handles storage, retrieval, and execution.
Securely Exposing the MCP
Like my other local MCP integrations, exposing this internal service to external AI clients required a secure boundary. The system runs behind a Cloudflare Tunnel that is natively bundled into the project’s docker-compose setup. This creates a secure, outbound-only connection without opening any local ports.
To ensure only I can access the system, the tunnel sits behind an OAuth proxy using GitHub OAuth. Only my specific GitHub account is authorized to connect to the MCP server. This provides a strict authentication wall, allowing me to safely expose my private pipeline to cloud-based LLMs.
From Articles to a Personalized Podcast
The podcast workflow is deliberately session-based.
A client starts a podcast draft, appends chunks of dialogue, and finalizes only when the draft is substantial enough. The server validates structure, stores temporary chunks, tracks progress, and then renders the audio in the background through a TTS service.
The key idea is that the LLM is not being asked to do everything in one shot.
Instead, the workflow is broken into explicit steps:
- retrieve the most relevant articles
- load full content for the selected sources
- generate a grounded dialogue from those sources
- append the dialogue to a persisted podcast session
- finalize when quality thresholds are met
- render the final audio asset
That decomposition improves reliability and makes failures easier to handle. It also makes the system more observable: I can see whether the draft is incomplete, ready to finalize, processing, or finished.
Once the MP3 is generated, I sync it to my phone with Syncthing and listen to it outside. The result is a personalized technical podcast generated from sources I actually care about, at a cost low enough to justify using it regularly.
Engineering Practices That Matter More Than Hype
Projects in this space often get presented as magic. I think the more interesting story is disciplined engineering.
A few choices mattered a lot:
- keeping the application layer independent from infrastructure details
- using protocol-based design to keep services testable
- isolating background job state and ingestion locks in the MCP server
- applying timeouts around semantic operations so failures degrade predictably
- storing both article-level and chunk-level representations for future retrieval flexibility
- keeping the podcast subsystem explicit rather than burying it inside a monolithic prompt
There is also a practical testing story behind the project. Unit tests cover the crawler orchestration and podcast service lifecycle, while integration tests cover PostgreSQL persistence and similarity retrieval. That is not glamorous, but it is exactly what keeps an AI-adjacent system maintainable.
Cost, Leverage, and Signal
From a product perspective, this project is intentionally asymmetric.
The ingestion side uses a cheap LLM model because enrichment is repetitive and cost-sensitive. The interactive side benefits from a stronger client experience because that is where source selection, synthesis, and dialogue generation create value. By separating those roles, the system stays affordable without becoming simplistic.
From a career perspective, this project also reflects the kind of engineering work I enjoy most: designing systems with clear boundaries, choosing the right level of abstraction, and using LLMs where they add operational leverage instead of noise.
It is easy to build demos in this space. It is harder, and more interesting, to build something that is structured, testable, cost-aware, and genuinely useful in day-to-day life.
Closing Thoughts
Better ArchNews is a small project, but it represents a pattern I expect to use more often.
LLMs are much more useful when they sit on top of a well-designed system than when they are asked to replace one. In this case, the durable value comes from the architecture: a pipeline that enriches content, a vector store that supports retrieval, an MCP surface that keeps client interactions efficient, and a podcast workflow that turns the output into something I will actually use.
That combination is what makes the project interesting to me. It is not just a content pipeline. It is a practical example of how software design, retrieval architecture, and low-cost LLM orchestration can be combined into a tool that earns its place in a real routine.
I am heading out with my podcast. Have a great Friday, see you!