This is the first post in a series about Punchcard Central, the platform we built this year to run Punchcard.
It started with a personal agent I had built for myself and a client meeting earlier this year. Before the meeting the agent went through our past meetings with that client, my own notes on the account and the time the team had logged on the project, and sent me a prep note. It helped me focus and shared with me things I would not have remembered to bring up. I probably knew most of it already, the information was all sitting in systems I had access to, but I hadn’t brought it together. When you have meetings back to back you don’t always get the time to reflect and prepare for the next meeting. When the client asked what had been done in the last sprint, the answer was right there in front of me. It didn’t lead to more work, but it made for a much smoother working relationship.
Where It Started
Over the Christmas break in 2025 I started building a personal vault of markdown files that recorded pretty much everything, my one-on-one notes, work relationships and project statuses. In January I moved to NanoClaw to run agents on it, and not long after that I built my own. The agents could see my calendar, Teams, SharePoint and our Harvest time entries along with my personal information, and they ran in containers on my own machine. I built a fair bit of routines on top of it and it was saving me a lot of time. The biggest thing it helped with was context, I could ask it a question and it would pull from different parts of my work to put an answer together.
Giving agents that kind of access needed safeguards. I built a custom MCP server on its own application registration with very restricted access to Microsoft Graph, and every request the agents made was checked deterministically, by code or by me, never by another AI. That was fine for one person but it isn’t something you can roll out to a company. When I showed people what my agent was doing they wanted it too, and there was no way to give it to them securely.
At the same time the company had a transcript problem. The way permissions work in Teams, a meeting transcript is often hard to get to unless you organized the meeting. We built a small automation that copied each transcript into the channel the meeting was held in, so anyone who attended could read it without having to ask the organizer.
I was getting so much value out of my own agent setup that it seemed crazy the rest of the company couldn’t have it. Looking around I didn’t see a product that did it, everything was too new. Around the same time I was listening to some Y Combinator talks about building companies with AI, and it seemed like there was an opportunity for Punchcard to do more. I also wanted to see how far I could push it.
Why Not Copilot
We are a Microsoft partner and we already have Microsoft 365 Copilot, so this is the obvious question. Copilot can see what lives in Microsoft 365, but it can’t see Harvest or a lot of our other sources of information, and the governance and tooling around it is fairly challenging. What it can do today is actually not bad. What it could do when we started was not nearly as good, and it turned out to be more effective to build our own search index than to rely on what Copilot could reach through Microsoft Graph. If our organization was structured differently it might be the right tool, for us it isn’t. We also write code for a living, so learning how to build this matters to us.
The Reframe
The original plan was fairly ordinary. Punchcard had too many disconnected systems (Harvest, Forecast, Planner, Loop, OneNote, SharePoint lists and Power BI) and no single source of truth, so we would build one system to replace them. On May 23 I wrote the first architecture decision record for the project and the framing changed. Instead of one tool replacing a dozen, Central would be an intelligence layer, a place where what the company produces is captured and structured so agents can work with it.
The same day we added an Outcome entity to the design, one named person accountable for each recurring outcome, usually called a directly responsible individual or DRI. That decision turned out to matter as much for how we organize Punchcard as for the software. An intelligence layer can surface a problem, but if nobody owns the outcome nothing happens, and a company can only assign that kind of ownership if it can see the work clearly. We started mapping every recurring outcome in our delivery practice to a single owner, and Central became the place where those owners and outcomes are managed. The organizational change is the reason for the tooling, and the tooling is what makes the organizational change possible, I don’t think either one works without the other.
The reframe came from how quickly we could build the UI. As people brought ideas forward we could build them almost immediately, it was a bit shocking how fast it went. It also showed how quickly we could build something bad. A bad idea used to mean weeks of wasted time and energy, now we just replaced it with something good. That takes away a lot of the psychological barrier to trying new things. Early on we were very divergent in our features and designs, later we had to converge and throw away the experiments that didn’t work.
The phrase we ended up with is disposable software, durable context. The screens are throwaway, the data and the relationships between the data are what lasts. Once we put the hard engineering work into a strong foundation we could build different views and different ways of working with the data in a ridiculously short amount of time. Recognizing how easy it had become was a real shift in thinking for us, because it changes what you can attempt.
Safety
We talk a lot about psychological safety at Punchcard, people won’t bring fresh ideas if they are worried about what happens when they are wrong. Code works the same way, developers used to be afraid to experiment because changing one thing could break something somewhere else and nobody knew whether it was safe. Central has a large suite of back-end tests, which has grown to about 4,000 now, so we can experiment without worrying about that. If you want to change your organization for AI and change your code for AI, safety has to exist in both places.
If You Want to Start
Build a solid backbone first, vibe coding has its place but for the core of a system like this I would argue for vibe engineering, which brings more rigour to the process. We built Central on PunchcardCore, our internal platform template, which already had security and a permission model in place, which is a big part of why we could move so quickly. It is better to spend a little extra time being safe at the start.
Own your data, if a system that matters to your organization lets you extract data through an API, you should be doing that and putting the data somewhere you fully own. MCP is great for getting a single piece of information, but if you want to run an analysis across 5,000 entries you can’t do it well one tool call at a time. It’s much more efficient to have the data in your own store and use deterministic code for the analysis, with AI helping you write that code. You also don’t want to be at the mercy of another company changing its pricing, rate limits or throttling.
Don’t trust the AI with privacy and security. You need to understand the code and review it. When we give agents access to different parts of our data we shape that context carefully. A lot of the people I see struggling with AI don’t have the environment it needs to work well.
Expect to get it wrong more than once, we didn’t get it right the first time or the fifth, and the models keep changing underneath us. This isn’t something you roll out once, we ship small improvements every week and change management is part of the work.