I've noticed I evaluate software differently than I did a year ago. It wasn't a deliberate shift. But I find myself paying less attention to what a tool does on its own, and more to whether anything outside it can reach what's inside.
For decades, software companies built value by locking functionality into modules. Pay for the next tier to unlock the feature you really need. Buy the add-on every twelve months. Upgrade the seat to fix everything.
That model worked extremely well. For the software companies.
It's getting harder to justify now, and AI is a big reason. But AI is too general a label to explain why. Those same software companies sell AI too.
What actually changes the math is narrower: AI working between your tools rather than inside them. Moving the information and doing the work, in the same motion. That single layer is starting to satisfy work that used to require ten different modules stitched together.
The distinction matters because AI built inside a tool only sees what that tool sees. That isn't a model quality problem. Everyone is calling the same handful of frontier models. It's a boundary problem. A feature that tags your files can't check them against the product line plan living in another system, because that document isn't inside its walls. The feature works exactly as advertised and still leaves the interesting half of the job undone.
I should name the tension here, since I sell software. Collage is a subscription like anything else on your list. But the tools I've stopped paying for and the ones I'd renew tomorrow split along one line: modules get cancelled, substrate doesn't. If a tool holds data that other systems can't reconstruct, and it lets those systems reach it, it isn't on the chopping block. If its value was mostly the interface, it is.
We Started Late Enough to Build This Way
Collage is going on three years old. For most things that's a disadvantage. For this one it wasn't. We never had a decade of accumulated tooling to unwind. When we picked systems, the question above was already the question, so we chose tools that other systems could access. Tools where the value could easily leave their platform walls and compound with others. Notion, Linear, Figma, Anthropic, Amplitude… chosen less for any individual feature and more because our operating context doesn't get stuck inside them.
Two of the changes I didn't plan on:
We ditched our CMS. Not because it was bad. Because once the content lived somewhere our own systems could read and write directly, a separate application for managing it became an unnecessary step creating unnecessary friction.
And we largely stopped working inside our CRM. It's still there and it's still the record. But it functions more as a data source now rather than a place we spend the day. Scoring and sequencing happen in systems we built, which do that job better for us than a general-purpose interface can, and which read from the CRM instead of asking someone to go interpret it.
Neither of those was a feature upgrade. Both were consequences of the data being reachable.
The value isn't created by the next great feature.
Value now, for us today and for more companies in the future, comes from how much of our real operating context an AI system can actually read and act on.
That question, what an AI system can actually access, is the first one I'd ask about any tool in your stack.
If your systems are reachable, AI can do the work without a person manually bridging every gap.
If they aren't, your team members become the bridge. Every workflow runs through a translator, moving data by hand from the tool that holds it to the tool that needs it. That's a tax you're paying today, every time someone exports a CSV or copies information between systems that could already be talking to each other.
Access Cuts Both Ways
Reach isn't the only variable, though, and I'd be selling you something dishonest if I left it there. Read access and write access get talked about as one thing. They aren't. Broad read access to disorganized data gets you confident, wrong answers. Broad write access gets you confident, wrong answers that are now saved and potentially amplified.
That makes the people side more important, not less. A connected, AI-supported stack still needs someone who understands the systems, the data, the permissions, and the business judgment well enough to decide where automation should help and where it should stop. The dependency shifts from people manually bridging gaps between tools to people designing the bridges, maintaining the rules, and keeping the system honest.
So the reach question travels with a second one: what has to happen before anything actually changes? Our answer has been that consequential operations get proposed rather than performed. The system states what it intends to do, at whatever scale, and a person approves it. That sounds like friction. It's the opposite. It's the thing that makes handing over the boring ninety percent possible at all.
A Simple Mar-Tech Audit
Picture your marketing tools list.
Go down it and ask one question about each: if an AI system could already read everything inside this tool, what would I still be paying for?
For some, the answer is obvious. They hold data nothing else can reconstruct, and everything you connect to them compounds. Those get more valuable, not less.
For the rest, the honest answer is that you're paying for the interface. Project management, content storage, internal docs… the list is long. These tools have been valuable because they organized resources for humans to access, and that was real work.
If an AI system can read that same information directly, connect it to other tools, and act on it, the tool's job shifts completely.
The future of DAM, and a lot of software, isn't being a destination people log into. It's being the system your team's AI tools can reach, with the rules still attached when they get there.
Nobody Signed Up to Be a Systems Administrator
What doesn't get said enough: most marketers never wanted to become experts in stitching together a dozen disconnected tools. It's a job requirement, and smart individual contributors do it at a high level. Sometimes this kind of work gets rewarded internally.
But nobody took a marketing job because they love learning the quirks of six different platforms, keeping tribal knowledge of which export format works with which import field, or being the one person who remembers why a workflow breaks if you do it out of order.
That complexity got treated as normal because there wasn't an alternative. There is one now, and it's early, and it's still worth starting.
This Isn't a Knock on What Came Before
This piece, and those that follow, aren't knocks on the companies that built the last generation of enterprise software.
Many built real value, and a lot of that value came from the discipline of organizing data that used to live in email threads, spreadsheets, and physical paperwork.
The shift toward openness doesn't erase that foundational work. We're moving to the next layer of value, which comes from how connectable data is, not how contained it is.
The uncomfortable part is that this test doesn't spare your own product. A DAM designed only as a place people log into, browse folders, and download things is hard for anything else to reach, by construction. That's the assumption we've had to give up, and it has changed more about what we build than any competitive feature comparison ever did.
Giving up that assumption isn't the same as walking away from the interface, and I want to be honest about the timing. Most teams aren't working this way yet. On any given day, the majority of what people do in a DAM is still log in and find a file, and that has to be good or none of the rest of this matters.
What I didn't expect is how little tension there is between the two. The work that makes a library legible to an AI system — accurate tags, current versions, clear rights, real approval state — is the same work that makes it findable by a person. Most bad DAM experiences are bad data wearing an interface.
The teams that move fastest over the next few years won't be the ones with the most features.
They'll be the ones who can ask an honest question about every tool they use: is this something AI can act on, or is this something that creates more friction for our team?
Marketing and brand teams sit right in the middle of this shift, because brand content is rarely connected and highly siloed.
In Part 2, I'll dig into what connectivity actually looks like from a marketing and brand perspective, and why the decisions you make about governance now determine how much AI can actually do for you later.
