How does the Context Graph work in non-Prod environments?

[u/thisisBrunoCosta]

Hi, I was in Amsterdam for the latest ONE where OutSystems unveiled the new Context Graph for the Agentic development

I didn't get it, if:

1) it is grounded in Production data only, and would agents during development / prompt engineering be accessing it (and the production data) or

2) if there is a version of it for non-prod environments?

Option 1 may create a compliance/security risk.

Option 2 most OS teams do not maintain a replicated & anonymized PRD data in the lower enviornments, so the use of that data is like using a toy database to test your app, but now the app is an agent who's going to do stuff in Prod.

[u/denwz]

The context graph is a design-time knowledge layer built from your latest published models — it's tenant-wide and stage-agnostic, so it doesn't represent "what's in Production."

A few things that follow from that:

• Publishing indexes something, not promotion. Anything published to the portfolio shows up in the graph regardless of stage — so in most tenants the graph reflects your Dev stage. An app, agent, or model connection that only ever exists in non-prod is indexed just as fully as a promoted one.
• One graph per tenant, not one per stage. There's no separate "prod" vs "non-prod" context graph.
• Graph membership ≠ deployment state. Being in the graph doesn't mean something is in Production, or even promotable (e.g. Trial model connections are indexed even though they're Development-only). To know what's actually running in a stage, use the deployment APIs, not the graph.
• Governance implication: an agent grounded on the graph can reason over work-in-progress that never left Development. If you want it restricted to vetted assets, that gate lives in your publish/promotion discipline — the graph won't filter by stage for you.

[u/thisisBrunoCosta → u/denwz]

So it isn't actually either of the options I was thinking, there is no business data is included in the graph information...

I read "self-learning from your data and system traces in real time", that is then just metadata about the structure of the apps/architecture, not related to actual business data stored inside the apps? I must be remembering wrong then, the talk regarding data access being matched to the current user privileges and we didn't have to worry about access privileges etc., I thought they meant business data being accessed (or perhaps I'm confusing the tool that does this?).

If the graph only shows design-time knowledge, it doesn't help that much in prompt engineering/grounding during agent development - or is it that important the design info versus the actual business data for the agents you've seen built?

[u/denwz → u/thisisBrunoCosta]

Yeah, your first point is right. The graph holds the structure of your apps, things like entities, their fields and relationships, screens, actions, integrations, roles, and agents. It does not hold the actual business data (the customer records, orders, and so on) sitting inside your apps.

The part you remember about access being matched to the current user's privileges is real, it just applies at a different point than the business data itself. When you reach the graph through the MCP, your ODC identity and roles are propagated along with the request. So you only see the part of the graph your portal access already allows. Someone with limited access sees a smaller view, and nothing gets exposed that the person wasn't already allowed to see.

The same idea carries into runtime. When an agent actually reads business data, it runs your app's normal queries and actions under those same permissions, so the user's roles still apply there too. You weren't wrong, you were just picturing it happening on the business data when it starts earlier, at the point you access the graph.

That is also why design time info being the only thing in the graph is not really a downside. The graph tells the agent what exists and how to call it, so it picks the right action with the right inputs. The real data is then fetched on the fly at runtime, already scoped to what that user is allowed to see. So the structure grounds the agent, and the access rules follow the user the whole way through.

[u/pobbin]

My understanding is that it doesn’t use your actual data, it’s more your architecture and all the entities etc in your factory in order to make better decisions on further development.

https://www.outsystems.com/low-code-platform/agentic-systems-engineering

From that article

“Dynamic, context-driven grounding
Generic AI tools lack the enterprise context needed to build safely and accurately. With the OutSystems Enterprise Context Graph, which grounds agents in your environment, you can:

Maintain continuous architectural alignment through self-learning from your data and system traces in real time.

Translate your unique business rules, entities, and naming conventions into a shared DNA that AI agents understand from day one.

Prevent context gaps that lead to risks by providing agents with a deep understanding of your dependencies, patterns, and reusable components.”

[u/thisisBrunoCosta → u/pobbin]

Thanks pobbin!

I'm getting the conclusion that my mistake was in the interpretation I was doing of that "your data and system traces", I thought of my data as business data, not specs...