tech-news-agent
What it does
tech-news-agent is a multi-agent pipeline that takes a technology topic as input and produces a fact-checked, LinkedIn-ready post as output. An OrchestratorAgent runs a ReAct (Reason + Act) loop, coordinating five specialized agents — Scout, Reporter, Editor, FactChecker, and LinkedInWriter — and automatically retrying the fact-extraction step when the confidence score falls below a threshold. The entire pipeline is driven by the language model's reasoning; no Java code hardcodes the retry condition.
How it works
How the orchestrator decides to retry
The OrchestratorAgent operates in a tight loop: it reasons about the current state, issues a tool call or agent dispatch, observes the result, and decides what to do next. When the FactCheckerAgent returns a confidence score below 0.6, the model itself decides — based on its system prompt and the returned score — to send the article back to the Reporter for a second round of fact extraction. There is no if-statement in the Java code that checks the threshold; the model's own judgment drives the loop.
How facts are gathered
The ScoutAgent uses two tools: the Tavily Search API for live web search and a page-fetch utility for reading full article text. It also queries GitHub data through a GitHub MCP (Model Context Protocol) server, allowing the agent to examine repository metadata alongside news content. The gathered facts are counted and passed to the Reporter as a structured input.
How the pipeline handles long contexts
A ContextSizeAdvisor monitors the cumulative token count across the conversation and prunes or summarizes earlier turns before they exceed the model's context window. Each agent has its own dedicated system prompt stored under resources/prompts, so the model always knows which role it is playing, regardless of how many turns have accumulated.
Design decisions
- ReAct (Reason + Act) was chosen over a fixed pipeline because real articles require adaptive behavior: the number of search queries, the depth of fact-checking, and the need for a retry all depend on the content.
- The retry threshold of 0.6 is a guideline communicated to the model through its system prompt, not a hard-coded guard in Java — this is intentional to allow the model to override it when context makes a lower-confidence article acceptable.
- Using a GitHub MCP server rather than a direct API client means the agent can be granted GitHub access without embedding credentials in the application code.
- Spring AI 1.0's tool-calling API abstracts over the model provider, so switching from GPT-4o-mini to another model requires only a configuration change.
- One POST endpoint returns the entire enriched result — post, verified article, confidence, fact count, and timing — rather than streaming partial results, because the consumer (LinkedIn) expects a complete, editable draft.
Stack
| Layer | Technology |
|---|---|
| Framework | Spring Boot 3.5.0 |
| AI/ML | Spring AI 1.0.0 |
| AI/ML | OpenAI gpt-4o-mini |
| Library | Tavily Search API |
| Library | GitHub MCP Server v0.6.2 |
| Spring | Spring WebFlux (WebClient) |
| Language | Java 21 |
| Infra | Maven |