Blog / Product

Why We Changed What Action Log Is For

It started as a meeting follow-up tool. It became the one place I check to see how the whole plan is going.

By Glen Conway, Founder · November 8, 2026 · 5 min read

When I started building Action Log, I was solving my own problem. I was a VP and CISO, and later a CTO, and in every one of those roles I sat through a weekly status meeting that went row by row through a spreadsheet. Most weeks, most rows had not changed. Some weeks nobody had an update at all. It was an hour we never got back.

So the first version of Action Log was an action tracker for people who run projects. You captured what was agreed in a meeting, gave each item an owner and a due date, and Action Log reminded people between meetings so the next call did not start with "where are we on this?"

That still works, and it is still in the product. It is just no longer the reason I open Action Log every morning.

What changed

Two things happened at about the same time.

The first was that turning a meeting into a task list stopped being special. Otter, Fireflies, Microsoft Copilot, Zoom and most video tools now write the action items down for you. If your team already uses a notetaker, that part of the problem is largely solved. (We wrote about the part that is still missing in Your AI notetaker captured the action items. Now what?)

The second was that I started paying attention to how I actually used Action Log, and it looked nothing like the original plan. I was not typing in actions after meetings. The work was already tracked in Jira, Azure DevOps and Basecamp, and the context was scattered across email and comment threads. What I needed was one place that pulled all of that together and told me which parts of the plan needed me.

So that is what Action Log is now.

How I use it today

My week looks like this:

• Teams keep working where they already work. Action Log links to items in Jira, Azure DevOps and Basecamp and keeps their status and assignee in sync. Nobody copies updates from one tool to another.
• An AI assistant fills in the context. Each morning I ask my assistant to go through Basecamp, my email and Azure DevOps and bring Action Log up to date. It connects to Action Log through its MCP server, so it can post an update, move a date or flag a blocker on the right item. I happen to use Claude, but ChatGPT, Cursor, GitHub Copilot or any other assistant that supports MCP works the same way. The setup steps are in Action Log now works with Claude, Copilot, Cursor, and any MCP-compatible AI.
• Most days I only read the workstreams. A handful of cards tells me which areas are on track and which are not. I open one only when it needs me.
• Once a week I review the scorecard. I ask my assistant to go through it with me, then I copy the result into the scorecard our board uses, which lives in a different system.

I no longer read a long action list, and I no longer chase people for updates the day before a board meeting.

Why workstreams matter more than actions

A list of two hundred actions is hard work to read. You scan for anything red, you lose your place, and at the end you still cannot say whether the plan as a whole is on track.

Workstreams group those actions by area of the plan, such as hiring, platform reliability, a product launch or cash. Each one rolls its actions up into a single status (On track, At risk, Quiet or Blocked) with the reason in one line. Blocked dependencies show on the card, and so do areas where nothing has moved for a while. I can read six cards in a minute and know exactly where to look. When something needs attention, I click into that workstream and see only its actions.

Each workstream can also have an owner, the same way a board scorecard names someone for each area. That is what makes the weekly scorecard close to automatic: every row already has an owner, a status, what changed this week and the next step. You can see how this looks on the home page.

Who Action Log is for now

Action Log is built for executives who report to a board or a leadership team, where the work is spread across more than one tool. You will probably recognize some of this:

• Status lives in three or four systems, plus email.
• You rebuild the same summary every week for someone above you.
• Your status meeting is mostly people reading out things that did not change.

If you run one team in one tool, that tool's own reports are probably enough. Action Log earns its place when the picture is spread across systems and you are the one expected to explain it.

What has not changed

The meeting features are still there. You can paste a transcript or meeting notes and Action Log will propose actions with owners and dates. People outside your team still get a personal link to update their own items without creating an account. Owners still get a daily summary of what is due soon and overdue.

These features now feed the same view as everything else. A decision from Tuesday's meeting and a status change in Jira end up in the same workstream.

Facts from your tools, context from your assistant

From Jira, Azure DevOps and Basecamp, Action Log syncs the two things that decide whether a workstream is healthy: each item's status and who owns it. Those stay current without anyone touching them.

The story behind a status change usually lives somewhere else, in a comment thread, an email or a meeting. Your AI assistant reads those for you and adds a short update to the right item, such as "vendor confirmed the new date" or "waiting on legal sign-off". You get the explanation without a copy of every thread, so the view stays short enough to read in a few minutes.

GitHub and Monday integrations are next.

Try it on your own plan

New accounts start with a small sample plan that already has workstreams and a scorecard, so you can see how it reads before connecting anything. After that, connect one tool, connect your AI assistant, and see whether your next status meeting is shorter.