The Grounding Layer: Why OutSystems Opening Up Changes Everything
- João Sousa
- 20 hours ago
- 7 min read
Tools will change in six months. Models will change in three. What stays with you is the context you have built, and that is the part nobody is talking about enough.
TL;DR. Tools and models will keep changing. What stays with you is the context you have built: your architecture, your business rules, the way your systems fit together. The OutSystems Enterprise Context Graph, and the decision to open it up to agents like Claude Code, Codex, and Cursor, matters because it turns that context into the grounding layer any agent can plug into. Openness is not a feature. It is the thing that protects you when the tooling layer shifts again, and it only works if the governance and rails underneath stay in place.
I was scrolling X the other day and a post from Andrej Karpathy stopped me cold. He was making the point that we are all still designing software as if the user on the other end is a human clicking through screens we carefully arranged for them. And suddenly, in a world where agents are doing more and more of the work, that pattern feels rude.
Now, I want to be careful here. UI is not going away. For a huge number of users, the interface is the product, and a well-designed screen is still the best way to get something done. That is not changing. What is changing is that a growing class of users, call them developers, architects, builders, the people who are about to spend the next few years creating the agents that power everything else, do not need a UI for most of what they do. They need a platform that talks back programmatically. They need something an agent can reach into, understand, and act on without having to pretend it is a human clicking buttons.
That shift is the real story behind the Agentic Systems Engineering announcement. And the part of it I want to talk about, because I do not think it gets the attention it deserves, is openness.
The uncomfortable truth every architect is feeling right now
Let me say the quiet part out loud. The tools I am using today are almost certainly not the tools I will be using in six months. The models change faster than that. Every week there is a new repository, a new agent framework, a new way of working that promises to be better than what I was using on Monday. Sometimes it is. Sometimes it is not. Either way, I cannot tell you with any real confidence which assistant I will have open in my second monitor by the end of the year.
This is not a complaint. This is just the reality of the space right now. But it raises a hard question for anyone doing serious enterprise work: if the tooling layer is this volatile, what do I actually build on that will survive the next shift?
Tools move. Context stays.
This is the thesis. The data that grounds those models is where continuity lives. Your architecture, your domain model, your business rules, the way your systems actually fit together. That is yours. That is what travels with you when Mentor gets a new capability, when Claude Code ships a breaking update, when some tool I have never heard of becomes the new default three months from now.
I think about it in layers.
There is personal intelligence, the patterns I have learned over years of building, the prompts that work for me, the way I like my agents to behave. That travels with me from project to project, job to job. It is mine.
Then there is team intelligence, the shared version of that same idea. The conventions my squad has agreed on, the codebase knowledge we draw from, the shortcuts and guardrails we have built up together. That travels with the team.
And then there is the proprietary layer. The architecture of the applications, the business rules that run the company, the integration patterns that took years to stabilize, and the domain language nobody outside the organization understands. That one is not yours, and it is not the team's. It belongs to the organization, and it must never be rebuilt from scratch every time a new tool shows up at the door.
If any of those three layers is weak or missing, your agents are guessing. They will get the happy path right and then quietly make a mess of everything else. I have seen it. Most of us have.
Why a closed ecosystem quietly breaks this idea
Here is the trap I want to flag, because it is easy to walk into. If the only way to use AI inside your platform is to use that platform's single built-in assistant, you have just reintroduced vendor lock-in with a new coat of paint. Maybe it is a very good assistant. Maybe it is the best one available today. It will not be the best one available in a year.
More importantly, different tools are good at different things. I want to use Claude Code for the things Claude Code is best at. I want Mentor for what only Mentor can do inside the OutSystems platform. I want Cursor, or Codex, or whatever comes next, when the job calls for it. That is not me being difficult. That is me doing my job well.
None of that works if each tool has to build its own private understanding of my system. If Claude Code has one map, Mentor has a different one, and Cursor has a third, then I am not orchestrating agents, I am refereeing them. And at enterprise scale, that fragmentation is how you get AI sprawl, the exact kind that introduces risk you will not see until it is already in production.
What OutSystems is actually opening up
This is where the announcement matters, and where I want to be precise about what it is and what it is not.
The Enterprise Context Graph is a knowledge layer on top of your applications. It holds the structure and architecture of your system: entities, actions, timers, screens, widgets, how they depend on each other, and the metadata for each of them. Any agent that can plug into it gets the same map. Mentor uses it today. OutSystems has announced that other coding agents are next, and if that opening up is done right, not just a few shallow APIs but real access to the context, that is the piece I have been waiting for.
Because it means I no longer have to choose. I do not have to pick between Mentor or Claude Code, between the OutSystems assistant or Cursor. I can use all of them, working in the same system, following the same rules, grounded in the same context. The tooling layer becomes genuinely pluggable, and the grounding layer stays intact underneath.
That is what real openness looks like. Not a marketing line. A knowledge layer any agent can ground itself on, and a runtime that keeps the rails in place while they do it.
The part nobody is talking about enough: governance
Openness without governance is chaos. Governance without openness is a cage. You need both, and the combination is much rarer than people realize.
OutSystems has spent more than two decades building the governance and cloud management layer of the platform. Deployments, observability, access control, audit trails, the dull but critical machinery that makes enterprise software actually work at scale. That was already there. What the ASE announcement does is give agents, any agent, a way to plug into that machinery instead of trying to recreate it badly on the fly.
When an agent in a closed-world tool stands up a deployment pipeline from scratch, it will miss edge cases. It will forget the audit step. It will happily make a change that should have triggered a review. Not because the agent is malicious, but because it has no idea the review was supposed to happen. It was never told, and it had no way to find out.
When the same agent operates inside the OutSystems grounding layer, that context is already there. The guardrails are already wired. The agent is not inventing the enterprise. It is working inside one. That difference is not cosmetic. It is the difference between a proof of concept and a system you can actually run.
What this means for the day to day
I want to be honest about what this changes for us as developers and architects, because I think some of the discourse around AI in development is either too doomy or too giddy.
The mechanical parts of the job are going to shrink. Wiring up yet another CRUD screen, translating a clear business requirement into boilerplate, rebuilding the same integration pattern for the fifth time this year, those get compressed. Agents are good at that now, and they are going to get better.
What expands is the part that actually requires a human. What should we build? Why does it matter to the business? Is this the right decision given everything else going on? How do the systems connect? Where are the tradeoffs? Where does risk live? Those questions are not going anywhere. If anything, we finally get the time to think about them properly instead of squeezing them in between tickets.
The job title might change. The role is moving from 'builder of applications' to 'orchestrator of intelligent systems.' But the core of it, judgment, taste, architectural thinking, understanding the business, is more valuable than ever. I genuinely feel lucky to be doing this work at this moment.
Closing
I think the platforms that will win over the next five years won't be the ones with the flashiest AI assistants. The model behind that assistant will be commoditized faster than any of us expect. The platforms that win will be the ones with the strongest grounding layer and the confidence to let any agent plug into it.
Openness is not a feature. It is an admission that no single tool is going to be the right tool forever, and that the thing worth protecting is not the tool but the context underneath it. That context is yours. Build it well, keep it clean, and let the tools come and go around it.
That is the bet I am making. And after watching this space for a while, it is the only one I think actually holds up.
Comments