Simplicity Is Not Fewer Tools — It's the Right Layer

The most effective system I've ever built is also the least impressive to look at from the outside. No flashy multi-agent dashboard. No twelve integrations listed on a settings page. Just one thing that knows everything, with agents that spin up on top of it when I need them.

I got there the hard way — by first building the complicated version.

Three tools, three bridges, one mess

A few months ago I had three separate tools running in parallel. A CRM I built myself. An email agent that sorted my inbox, extracted contacts and data points, and let me take actions on emails without opening each one. And a LinkedIn Chrome extension that saved contacts, companies, and messages directly from LinkedIn with one click.

Each one worked. That was the problem.

Because they each worked in isolation, I had to build bridges. The email agent needed a bridge to the CRM so extracted contacts could land somewhere useful. The LinkedIn extension needed a bridge so saved companies and people didn't live in a silo. And every bridge added a new thing to maintain, a new place for data to go stale, a new moment where I had to look something up in one system to do something in another.

Makes sense, right? Three inputs, one place they all want to go — obviously you'd connect them. But "connected" is not the same as "native." And I was living in the gap between those two things every single day.

What I actually did — and what changed

I stopped treating the email agent and the LinkedIn extension as separate products that talk to the CRM. I made them part of the CRM.

Email entities now live inside the CRM as first-class constructs. There are input workers that pull emails in, and output workers that send them out. The email agent still does everything it did before — sorting, extracting, surfacing what I need to act on — but now it operates natively. An email gets saved and it's automatically linked to the right person, the right company, the right event. No manual tagging. No copying contact info across.

When I send an email out, it already carries context from that person's record in the CRM. The email knows who they are because the system they live in knows who they are.

LinkedIn contacts now get automatically deduplicated and merged into existing data when I save them. If I already have someone in the CRM, saving them from LinkedIn doesn't create a duplicate — it just adds to what's already there. If they're new, they come in clean.

Agents spin up via Slack or Web on demand. I don't have a dashboard I log into every morning to check which system has what. I just ask, or I act, and the right thing happens.

Less clicking. Less looking up. Less copy-pasting. Genuinely — I notice the absence of it. That low-level friction I used to carry around is just gone.

Then I went to the pf1 launch

Last week I was at the launch event for pf1, Paperflite's platform of AI agents. The thing they demoed was a knowledge graph agent (you can see it at pf1.ai/agents/knowledge) — it pulls from every system a company uses, Dropbox, Drive, call recordings, whatever, and builds one unified knowledge layer. Written knowledge, unwritten knowledge, the tacit stuff like selling patterns and frameworks that people practice but nobody ever actually records anywhere.

Their framing was "one source of truth for every rep and every agent." The idea being that once you have that layer, you can put any agent on top of it — and that agent immediately knows everything, without you having to wire it up to twelve different sources manually.

I watched the demo and felt this very specific recognition. Not "oh interesting concept." More like "that's the same thing I just did, but for a whole company."

The pattern is identical. You have knowledge spread across systems. You have tools that each know a piece of it. You build bridges to move information between them and it's annoying and brittle. So you stop bridging and start consolidating — one layer underneath, flexible agents on top.

Simplicity is not minimalism

I want to be precise about this because I think it's easy to get it wrong.

Simplicity is not about having fewer things. I still have an email agent. I still have LinkedIn contact capture. I still have a CRM. The functionality didn't shrink — it grew. I can do more now, not less.

What changed is the architecture underneath. The infrastructure got leaner and more native. Instead of three things that talk to each other through brittle connectors, I have one thing with multiple modes. The complexity didn't disappear — it just stopped bleeding through to me.

That's the distinction I keep coming back to. Complexity bleeding through is the problem. You feel it as friction. You feel it as "wait, where is that contact? Did it sync? Why is there a duplicate? Let me open the other tab." That's complexity you shouldn't be carrying. It belongs in the system.

And agents are actually really good at carrying it, if the infrastructure they're sitting on top of is solid. If everything is native and connected, an agent can pull context without you having to tell it where to look. It already knows. Because the system knows.

What this means if you're building something similar

The instinct when you're building tools is to build them separately and connect them later. That's fine as a starting point — it's how you figure out what each piece actually needs to do. I don't regret building the three separate tools first. I needed to understand each one before I could consolidate them.

But at some point you have to make the call: is this "connected" or is this "native"? Are my agents operating on a unified layer, or are they each doing their own thing and I'm manually managing the joins?

If you're spending time copy-pasting between systems, that's your signal. If you're maintaining three sources of the same contact's information, that's your signal. If spinning up a new agent requires you to re-explain context it should already have — that's your signal.

The rebuild is annoying. It took me real time to pull the email and LinkedIn functionality into the CRM properly instead of just bridging it. But the hours I've saved since are not even close. And more than the time — I just think more clearly when I'm working. The overhead is gone.

Build the right layer once. Then put whatever agents you need on top of it. That's the version that scales without making you feel like you're constantly managing your own tools instead of using them.

This week: if you have three or more tools that share data through manual exports, copy-pastes, or Zapier-style automations — pick one and ask whether it should actually live natively inside another. Not connected to. Inside. The answer is probably yes more often than you think.