I wanted to build an AI agent.
Not just a chatbot or another application that sends a prompt to an LLM and displays the answer. I wanted to build something that could perform a useful job, make some decisions for itself and run automatically.
The project also needed to be reasonably simple. I didn't want a large infrastructure project with databases, servers and lots of paid services.
After throwing a few ideas around with ChatGPT, I settled on a daily AI news website.
The basic idea was straightforward:
Every morning, an AI agent searches the web for important AI news, decides which stories are worth covering, writes a daily briefing and publishes it to a website.
It seemed like a good way to experiment with agentic AI while also building something genuinely useful.
The idea
My main goals for the project were:
- Build and test an agentic AI application.
- Automate as much of the process as possible.
- Keep the architecture simple.
- Keep running costs low.
- Use technologies I already know.
For the website I chose Next.js, TypeScript and Tailwind CSS, hosted on Cloudflare Pages.
I've used this stack on several other projects, so I didn't want to complicate the experiment by learning another web framework at the same time.
The interesting part of the project would be the AI.
How it works
After a bit of brainstorming, I ended up with this workflow:
Scheduled GitHub Action
|
v
AI research agent
(OpenAI Agents SDK + web search)
|
v
Structured response validated with Zod
|
v
Markdown blog post generated
|
v
Cover image generated
|
v
Post and image committed to GitHub
|
v
Cloudflare Pages detects the change
|
v
Next.js builds the static website
|
v
New daily edition is published
There is no CMS and no database.
The generated articles are simply Markdown files stored in the Git repository.
That was a deliberate decision.
The AI research agent
The most interesting part is the news generator.
It's a TypeScript script called:
scripts/generate-ai-news.ts
This uses the OpenAI Agents SDK together with web search.
Instead of my code deciding exactly which websites to search and which queries to run, I give the agent an objective and some editorial rules.
Its job is roughly:
Find the most important AI developments from the previous 24 hours, prioritise credible sources, choose the most useful stories and explain why they matter.
The agent can decide what it needs to search for while carrying out that task.
That distinction is one of the reasons I consider this an agentic application rather than simply an LLM API call.
Let the AI research. Let code handle structure.
The agent returns structured data containing things such as:
- The edition title.
- Introduction.
- Stories.
- Summaries.
- Why each story matters.
- Sources.
- Tags.
- A "What to watch" section.
I use Zod (TypeScript-first validation library) to validate the response.
Once the data passes validation, ordinary TypeScript code converts it into the Markdown format expected by the website.
I like this separation.
The AI gets flexibility where flexibility is useful — researching, deciding which stories matter and writing about them.
Normal code handles the parts where I want predictable behaviour.
That includes filenames, dates, frontmatter, directories and the final Markdown structure.
It also means that if the AI produces something in the wrong format, the application can reject it rather than blindly publishing it.
Avoiding the same stories every day
One problem with a daily news site is repetition.
A major story can dominate AI news for several days, but I don't want the site publishing effectively the same article every morning.
To help with this, the generator is given headline information from recent editions.
The agent can still include an older story if something significant has happened, but it has some context about what has already been covered.
It's a simple solution, but so far it seems useful.
Generating the cover image
Once the article has been created, a second script generates its cover image.
scripts/generate-post-image.ts
This reads the newly created Markdown file and extracts the lead story.
The image prompt is then built using the lead story's headline, summary and explanation of why it matters.
The resulting image is saved using the same filename as the article.
For example:
content/posts/2026-09-16-ai-news.md
public/images/posts/2026-09-16-ai-news.png
The post then contains a reference to that image in its frontmatter.
Using the same filename stem makes it very difficult for an article and its image to become separated.
Markdown as the database
I considered whether the project needed some form of database or CMS.
It really doesn't.
Each daily edition is simply stored in:
content/posts/
The Next.js application reads these files during the build.
My lib/posts.ts code parses the frontmatter, sorts the articles by date and supplies the data used by the homepage, archive pages and individual articles.
This gives me several advantages.
The content is readable without any special software, it's version controlled in Git, it's easy to back up, and I can move the website to another static hosting provider without having to migrate a database.
It also makes debugging much easier.
If something goes wrong, I can open the Markdown file and see exactly what the AI generated.
Automating everything with GitHub Actions
The whole process is run by GitHub Actions.
The workflow lives here:
.github/workflows/daily-ai-news.yml
It can be started manually, but it also has a daily schedule.
The job:
- Checks out the repository.
- Installs the project dependencies.
- Runs the AI news generator.
- Generates the cover image.
- Runs a production build of the site.
- Commits any new article and image.
- Pushes the changes back to GitHub.
The commit is important because the website itself is hosted using Cloudflare Pages with Git integration.
When GitHub receives the new commit, Cloudflare detects it and starts another build.
A few minutes later the latest edition is live.
There is no web server running the AI application continuously.
The expensive work happens once each day.
Keeping the website static
Next.js generates a completely static version of the site.
During the build it reads the Markdown files and produces HTML, JavaScript, CSS and images in the out directory.
Cloudflare Pages then serves those files.
Search and filtering are also performed in the browser using the metadata already loaded from the articles.
There isn't a search server sitting behind the website.
Again, this is intentional.
The simpler I can keep the running website, the less there is to maintain.
What does the agent actually control?
One thing I've found interesting while building this is deciding what should and shouldn't be controlled by AI.
The agent has quite a lot of freedom during the research stage.
It can search for stories, follow different lines of investigation and decide which developments are worth including.
But once its research is complete, conventional software takes over.
The agent does not decide where files are stored, how the site is deployed or how Git works.
I think that's probably a useful pattern for building practical AI agents.
Give the AI freedom where judgement and reasoning are useful.
Use deterministic software everywhere else.
Keeping the cost down
Cost was another part of the experiment.
I didn't want an AI news site that cost more to operate than a traditional website.
The architecture helps with this because the AI only generates one edition per day.
It doesn't make an OpenAI request every time somebody visits the website.
Once an article and image have been generated, they're stored permanently and can be served thousands of times without another AI call.
The main variable costs are therefore:
- OpenAI model usage.
- Web search.
- Image generation.
- Any hosting or build usage above free allowances.
- The domain name.
Both the text and image models are configurable using environment variables, which means I can experiment with cheaper models and compare the results.
I'm currently much more interested in measuring the real cost than guessing what it should cost.
Things that can still go wrong
Automating publishing introduces an obvious problem.
What happens when the AI gets something wrong?
Zod can tell me that a story contains all the fields I expect, but it cannot tell me that the story is true.
It also can't guarantee that the source actually supports the claim being made.
Those are different problems.
The current version doesn't have a human approval step before publishing, so this is one of the areas I want to test carefully.
Things I need to watch include:
- Incorrect facts.
- Weak or misleading sources.
- Old stories presented as new.
- Duplicate stories.
- Overconfident summaries.
- AI-generated images that don't suit the story.
This is probably one of the more interesting parts of the experiment.
Making an agent run automatically isn't particularly difficult.
Deciding how much you should trust it is a much harder problem.
Is this really an AI agent?
Before starting this project, I was slightly unclear about where normal AI automation ends and an "agent" begins.
Building this has made the distinction clearer.
The scheduled GitHub Action isn't an AI agent. It's just automation.
The Markdown generator isn't an AI agent either.
The agentic part is the research process.
I give the AI a goal rather than a fixed sequence of searches. It can decide what information it needs, use tools to obtain it, evaluate the results and continue working until it has produced the required briefing.
The rest of the system is conventional software built around it.
For me, that's probably a more useful way of thinking about AI agents than imagining completely autonomous pieces of software controlling everything.
What I've ended up with
The project is fairly small.
There's a Next.js website, a couple of generation scripts, some Markdown files and a GitHub Actions workflow.
But the complete system can research a topic, make editorial decisions, create a finished article, produce an image, test the website and publish the result automatically.
And because the final website is static, the running infrastructure is about as simple as it gets.
That's exactly what I wanted from this experiment.
It gives me a real application for testing AI agents rather than another artificial demo, and there are plenty of areas I can experiment with next: better source checking, different models, cost tracking, editorial review and perhaps more specialised agents.
The interesting bit isn't really the news website.
It's seeing just how much of a useful workflow can now be handed over to an AI agent — and working out where it's still sensible to keep a human in the loop.
Try the site for yourself: https://sixsixai.com.