The Git Reporter: How a morning automation became a team of AI reporters managing a newspaper

It started as a Clawd automation project.

The first idea was almost naive: what if an agent could wake up every morning, look at what changed in code I was interested in: agents and understand why it mattered, write a small article, and post the result back to me?

Not a dashboard. Not a changelog. A tiny article made from source code. I wanted to read something I cared about rather than scrolling click-bait social media and news

The core belief was simple: a lot of important software change is visible in repositories before it appears in official announcements, product pages, or launch posts. If you read commits, pull requests, file movements, and architecture changes carefully enough, you can often see the story early.

So I gave the agent a job: follow the code, find the meaning, write the story.

The First Version Was Just a Morning Routine

The first working version was a scheduled Clawd/OpenClaw job.

Every morning, it had to:

• read what it published yesterday;
• avoid repeating the same topic;
• scan relevant repositories and trends;
• use git, gh, and gsio to ground the story in evidence;
• draft an HTML article;
• save notes and sources;
• publish the page locally;
• verify the URL;
• post a short trail log back to Discord.

That workflow mattered more than the website.

The website, at that stage, was just the place where the article landed. The real product was the loop: source code in, public explanation out.

The first successful daily run I found in the traces was on March 5, 2026. It published an article, created a research folder, saved its notes, updated state, and posted a local link.

It also failed at something immediately: one of the expected tools, gsio, was missing on that host.

I like that detail because it tells the truth about how these projects really start. The system was useful before it was clean. It published anyway, and it wrote down the missing part.

It Became a Real Editorial Experiment

Through March, the baseline automation kept producing daily articles.

The topics were already recognizably part of the same beat:

• MCP trust prompts;
• memory writes;
• tool discovery;
• JIT context;
• parallel tool scheduling;
• execution context;
• agent forensics;
• backpressure;
• narrative layers;
• permission conversations.

At some point, I added a second lane called agent-daily.

That lane was an A/B test. The first lane could follow a strong daily change in one or two repositories. The second lane had to look for broader patterns across multiple projects.

This changed the editorial center of gravity.

The best articles were no longer "this commit changed this file." They were more like: "three different agent runtimes are solving the same invisible problem in different ways, and that tells us something about where the field is going."

That was the moment The Git Reporter started to feel like a newspaper to me.

Not because it had a nice layout.

Because it had a beat.

Then the Automation Started Breaking

The failure story is not separate from the project. It is part of the project.

The original automation was ambitious, but it depended on a lot of fragile things:

• local servers;
• repo freshness;
• network access;
• model availability;
• OAuth tokens;
• Discord delivery;
• tool paths;
• and the agent's ability to keep context across isolated runs.

The traces show the pattern clearly.

The baseline job recorded 70 runs. Twenty-five finished successfully. Forty-five ended in error.

The successful period ran from March 5 through April 1, but even that period was not perfectly smooth. There were auth problems in mid-March. One article was written while delivery failed. Another run was aborted even though its summary still pointed to a published article.

Then April arrived, and the failures became the story.

From April 2 through April 7, the daily jobs repeatedly failed with network fetch errors. Starting April 8, the failures shifted to OAuth refresh errors. By May 12, both scheduled jobs had accumulated 41 consecutive failures.

That sounds bad, and operationally it was.

But it also clarified the architecture.

The automation had proved that the editorial loop was valuable. It had not proved that the whole newspaper should be directly coupled to a scheduled agent, private credentials, local machine state, and Discord posting.

That distinction matters.

The Automation Found the Product. The Failures Found the Architecture.

When I revived the project in May, I did not try to simply reconnect the old robot.

I built a private production workspace instead.

That workspace keeps the messy parts where they belong:

• recovered source material;
• process notes;
• candidate scans;
• repo caches;
• feedback;
• internal evidence;
• build scripts;
• validation tools.

The public output is a separate thing.

Articles can leave. Public evidence can leave. The generated static site can leave. But raw process traces, local paths, private context, and automation internals stay inside.

This was the big design shift.

The Git Reporter became less like "a bot that posts articles" and more like "a newsroom pipeline with a static public edition."

What It Looks Like Now

The current version has a clearer shape:

• a private workspace where reporting and drafting happen;
• daily article source files;
• evidence pages;
• a generated archive;
• an Agent Atlas section for longer explanations;
• a static site export;
• public repositories for sanitized content and hosting;
• a custom domain at thegitreporter.com.

The homepage is generated from the latest edition. Articles have receipts. The archive is grouped by date. The public site is static and boring in the best possible way.

The boring part is important.

After watching the original automation fail on credentials, network access, delivery, and local state, I want the public surface to be simple. Static files. Public evidence. No dependency on the morning job being healthy at the exact moment someone reads the article.

What I Learned

The project taught me something about AI agents that I keep seeing in other contexts too.

The exciting part is not the agent doing a task once.

The hard part is making the work repeatable, inspectable, recoverable, and safe to publish.

The old Clawd automation was exciting because it showed that an agent could behave like a junior reporter with a real beat. It could wake up, investigate, write, and leave a trail.

But the current version is more mature because it accepts that investigation and publication are different responsibilities.

Private investigation can be messy.

Public publishing needs a boundary.

That is probably the main lesson of The Git Reporter so far.

I still want the morning loop back. I want the agent to scan repositories, find candidate stories, prepare evidence, and draft the daily edition.

But I do not want to lose the boundary.

The next version should keep the best part of the original automation while respecting what the failures taught me:

private work inside, public evidence outside, and a newspaper front page that only shows what survived review.

That is the project I am building now.