Waxell

Project Tracking Table: Build Your First in Connect

Every new project used to mean another tracking tool to set up and keep in sync. Now I run the whole thing from one table my agent reads and updates itself.

Frances @ WaxellUpdated 9 min read

I am not a project manager and have never wanted to be one. For years my version of tracking a project was a tab open in a project management tool plus a note I kept meaning to update and didn't. The work got done, mostly. What I lost was the state of the work: what was finished, what was waiting on me, what I'd already handed to someone else.

The fix turned out to be smaller than the problem. One table.

A project tracking table in Waxell Connect is a live, agent-readable grid of rows and columns that you and your AI agents read and write to in the same place — so the record of who's doing what, and where it stands, stays current without anyone copying it anywhere. A row is an item of work. A column is something you want to know about that item: status, owner, priority, a link, a note. The part that makes it different from a spreadsheet is the second reader. An agent can open this table, see that three rows are marked "needs review," and act on them. It isn't looking at a picture of your project. It's reading the thing itself.

This is post fourteen in the Build Your First series, and it's the one I'd start with if you've only ever used Connect for one-off tasks.

Why a table, and not another tool

The honest reason is that I already had too many tools. So does almost everyone. BetterCloud's 2025 State of SaaS report puts the average organization at 106 different SaaS applications, and that's after two straight years of companies actively cutting back from a 2022 peak of 130. Adding a thirty-first app to track a six-week project is how you end up with a graveyard of half-filled trackers.

The cost isn't only the subscription. It's the switching. Moveworks, summarizing tool-fatigue research in early 2026, found that 22% of workers lose two or more hours a week to jumping between tools — about two and a half working weeks a year — and that more than half say the toggling makes their work worse. A separate tracker is one more place to keep in sync, and one more place the AI can't see unless I paste from it.

That last part was my actual workflow before Connect, and it's worth being specific about it. My project status lived in a project management tool. When I wanted my agent to draft an update or figure out what was overdue, I copied the relevant rows out of that tool and pasted them into an AI chat. The agent only knew what I pasted. Next session, the context was gone and I pasted again, usually a slightly different version because the source had moved on. The tracker and the AI never talked to each other. I was the integration, and I was a bad one.

Now the table lives in the workspace. Every Cowork session I open, I name the workspace, the agent enters it, and it reads the table before I've typed a word. No copy-paste. When I ask what's overdue, it already has the rows.

A quick disclaimer, because I don't want this to read as a Cowork pitch: that's just my setup. I use Cowork as my interface for Connect. Connect is also reachable through its API and web UI, so if you've built your own agent tooling or you're working in the browser, you get the same table behavior — the agent reading and updating the same rows you do.

Building it: the fifteen-minute version

Here's the whole thing, using a real example. I'll use a content project, because that's what I had on hand when I first did this, but the shape works for a launch, a migration, a hiring round, anything with a list of items that each move through a few stages.

Make a workspace for the project. One project, one workspace. This is the boundary the agent reads inside of, so keep it to a single effort rather than a catch-all.

Create the table and give it real columns. Mine had six: Item, Stage, Owner, Priority, Link, Notes. The columns you choose are the questions you'll want answered later, so resist the urge to add fifteen "just in case." I added Priority on day one and never used it for the first project. That's fine. You learn what you actually look at by getting it slightly wrong first.

You can also have an external agent create the table for you through the API. Hand it a list of columns and it builds the table in the workspace — same result, no clicking. I do this now for any project where I already know the shape of the tracker.

Add your rows. Each item of work is a row. For the content project, every article was a row, and Stage moved from Drafting to Review to Revision to Done. You can type these in, or you can hand the agent a list and have it fill the rows in one pass, which is what I do now that I trust it.

Decide what's a column and what's a state object. Most of the project lives in the table. But if there's one fact that several things depend on, like the launch date or the current sprint, that belongs in a state object, which is a separate live record the agent can read and update on its own. The table tracks the items; the state object holds the one shared fact. Keeping them apart saved me from burying the thing everyone needed inside row forty.

Let the agent update rows as work happens. This is where it stops being a spreadsheet. When the agent finishes drafting an article, it sets that row's Stage to Review itself. When I finish a review, I tell it, and it updates the row. The table is always current because the people and agents doing the work are the ones changing it, in the place the work is recorded.

Optional, and the part I'd add second: a scheduled task. I have one task that runs in the morning, reads the table, and posts a short status to the project channel — what moved, what's stuck, what's waiting on me. I didn't build this on day one. I built it once the table had proven it stayed accurate, because a scheduled summary of a stale table is worse than nothing.

That's it. No new login, no app to evaluate. The setup took me about fifteen minutes the first time, and most of that was deciding on columns.

What it didn't do well at first

The first table I built had a Notes column that turned into a swamp. I put everything in it, real blockers mixed in with stray comments, and within a week neither I nor the agent could tell one from the other. The fix was boring: I split blockers into their own column with a yes/no, so the agent could actually find them. The lesson I took was that a column the agent can act on beats a column that's just prose. If you want the agent to do something with a field, make the field answerable, not free-form.

It's still not a replacement for everything a dedicated tool does. There's no Gantt chart and no burndown view. For the projects I run, I have not missed them once. For yours, you might. Worth knowing before you tear anything down.

Where to start

Pick the project you're most tired of losing track of. Make a workspace, make a table, give it the four or five columns that are actually the questions you keep asking, and add your rows. Then leave the scheduled task for next week. The table earns the automation by staying accurate first.

If you want to try it, you can get access at waxell.ai/get-access.

FAQ

What is a project tracking table in Waxell Connect?

It's a live grid of rows and columns inside a Connect workspace where each row is an item of work and each column is a detail about it, such as status, owner, or priority. The difference from an ordinary spreadsheet is that AI agents read and update the same table you do. An agent can open it, see which rows need attention, act on them, and change a row's status when the work is done, so the tracker stays current without anyone manually syncing it.

How is a Connect table different from a spreadsheet or a project management tool?

A spreadsheet is read by people and stays static unless someone edits it. A project management tool is built for people to click through. A Connect table is built so an agent entering the workspace can consume it directly and write back to it. You're not maintaining a record on one side and an AI on the other; the table is the shared surface both work from. That removes the copy-paste step where you'd otherwise move context from your tracker into an AI chat.

Do I need a separate tool to track a project if I use Connect?

No, which is the point of building the table inside the workspace. The project's items, their status, and the notes around them live in one place the agent already reads. Given that the average company runs more than a hundred SaaS apps and people lose hours each week switching between them, the value of one fewer tool to open and reconcile is most of the reason to do it this way.

When should I use a state object instead of a table column?

Use a column when the information belongs to individual items, like each article's stage or each task's owner. Use a state object when one fact is shared across the whole project and several things depend on it, like a launch date or the current sprint. The table tracks the many items; the state object holds the single shared value the agent can read and update on its own. Keeping the shared fact out of the rows means nobody has to hunt for it.

Can an AI agent update the table on its own?

Yes. An agent working in the workspace can change a row's status, add a row, or fill in a note as it completes work, the same way you would. In my setup, the agent moves an item to "Review" when it finishes a draft, and a scheduled task reads the table each morning and posts what changed to the project channel. You decide how much the agent owns; it can do as little as record its own progress or as much as run the daily status itself.

How long does it take to set up my first table?

About fifteen minutes for a basic one, and most of that is deciding which columns you need. You don't have to get the columns right on the first try. I added one I never used and later split another into two. Start with the four or five fields that are the questions you keep asking about the project, add your rows, and refine the structure once you see what you actually look at.

Sources