Our knowledge system for building products.

Every morning I have an agent pull down the decisions waiting on me. It walks me through them and I approve, edit, or ask for more. No meeting, no prep, no deck.

This is possible with APEX, which stands for Agentic Product Execution. It holds everything anyone at Duetto needs to build a product: what we're building, why, who is building it, and whether it's shipped or still an argument.

I'm telling you this because that connectivity problem is not just experienced by software companies. Every business — a hotel as much as ours — runs on knowledge that lives in people's heads, in inboxes, in tools that don't talk to each other, and every business needs a way for the people doing the work to find that knowledge, act on it, and keep it current. What we built to solve that problem for ourselves at Duetto is useful to anyone carrying the same problem.

How APEX works.

Every document is a plain text (markdown) file with machine-readable labels at the top (owner, status, type, date), and its location says which team owns it. Changes arrive as proposals and get reviewed the way engineers review code. We've documented how APEX works from a technical standpoint here, for those who wish to dive into the detail: apex.duetto.ai.

What it changed for us.

The corpus (the collection of files inside APEX) is indexed for machines as well as people: semantic search, keyword search, and a graph of how documents relate. Our automated code review reads the change, then goes back to APEX to ask whether its intent matches the product's.

Some of the discipline is enforced by software rather than people. A spec can't be approved without an experiment on file that came back validated. An initiative can't enter delivery without a named executive sponsor — an actual person.

Where APEX came from.

My first week at Duetto there was an offsite in Dallas, product and engineering leadership talking about the future of development. Endless meetings, enormous documents and no way to trace anything had been my largest frustration in my previous job, CTO at TripAdvisor. Using a git (source managed) repository for all product and engineering knowledge is an old idea that kept failing, because it needs tooling before non-engineers can live in it, and that tooling used to be expensive. It isn't anymore. That's the part that actually changed.

I pitched the idea for APEX in Dallas on January 29. The first commit landed on February 7, under a name nobody would put on a slide: llm-supported-pdp-sdlc. Later that month, at a go-to-market offsite in Cancún, our CPO Kartik, one of our product VPs Sabrina, and I spent three hours refining what it should be. I recorded the discussion, transcribed it at home, and turned it into requirements. I wrote the browser app in March, everyone else came in through it in April, and in June we retired Confluence into it.

Is APEX a new concept?

Piece by piece, almost none of APEX is entirely new. Storing documents alongside code, recording decisions in writing, and reviewing proposals before acting on them are established practices. APEX brings those practices together and makes the knowledge usable by people and agents.

The combination we wanted was product and engineering knowledge in one repository, a shared review workflow, a browser front door for non-engineers, and agents that can propose changes through that workflow. I made one choice for one company that already lives in git, and that bet isn't settled.

How non-engineers use APEX.

Engineers work in the tools they already use. Everyone else has two doors. Anyone at Duetto can log into APEX Companion and read the product and engineering knowledge held there. Transparency is part of my philosophy, and I'd rather people see what I see. The second door is an assistant in Slack and in our company Claude.ai.

As of August 25, there were about 3,255 documents in APEX, roughly two-thirds of that is the migrated Confluence library. The rest, including 194 initiatives, was created in APEX itself and runs under the review model.

What this would look like for a hotel.

I get asked how any of this helps a hotelier. Understanding how the company operates and who does what matters as much to a hotel as a software company. Imagine a night manager who needs to relocate a guest: they should be able to find the approved procedure, who can authorize the expense, and when the guidance was last reviewed, without chasing someone who's off shift.

I'm not expecting anyone to build their own APEX, though it's more doable than it sounds. What I'd argue for is a company knowledge base: the documents, indexed so they're searchable, with the relationships between them visible. Instead of asking employees to track things down, you say, here is where the information that runs our business lives. Who owns housekeeping staffing, who owns supply, who owns invoicing, who our suppliers are.

I think of this type of knowledge base as a Jedi's lightsaber: something you shape around the work you need to do. You don't have to build the software yourself, but you do have to take responsibility for how the knowledge is organized, reviewed, and kept useful.

Four things to keep in mind if you're building an agentic knowledge system.

Here's the line I'd draw: AI and search should handle finding the right information, because that's finally possible to do well. What they shouldn't be mistaken for is a fix to how colleagues work together — that relationship was never the problem AI needed to solve. Good colleagues still make good business.

APEX doesn't make decisions for us. It keeps the reasoning in writing, where anyone (human or agent) can find it, so we can revisit a decision without reconstructing the whole discussion. That's the whole bet: build the repository well enough that people stop asking each other where the truth lives, and start asking it directly. The tools to fix this are cheap now, in a way they weren't a few years ago. There's no good reason left to run a business on knowledge nobody can find.