Two developments today came from very different parts of the agent stack.
Meta released Muse Glimmer, a 30B open model designed for local, always-on agent workflows. It can run on consumer hardware and is trained for tool use, long-running execution, multimodal input, and failure recovery.
At the enterprise layer, RealPage introduced the Lumina AI Suite, combining agents, a governed knowledge graph, operational intelligence, institutional intelligence, and MCP-based access to external models.
One development is pushing agents down onto local hardware.
The other is building more enterprise infrastructure around them.
Together they make an architectural question easier to see.
If the model can increasingly run anywhere, where should the organization's actual decision criteria live?
The model is becoming one component of the system
Consider a procurement agent reviewing a new vendor.
It might retrieve:
vendor identity
sanctions status
tax documentation
annual contract value
internal risk classification
budget information
Those facts could come from several places.
A knowledge graph can connect them.
An MCP server can expose them.
An identity system can decide whether the agent is allowed to retrieve them.
A gateway can determine whether the agent is permitted to call the vendor-management API.
But none of those necessarily answers:
should this vendor be approved?
That decision could depend on relationships between the facts.
A sanctions match might be a hard stop.
A particular spend threshold might require committee review.
Handling personal data might introduce another evidence requirement.
Missing tax documentation might mean the correct outcome is neither approval nor rejection.
It may mean:
insufficient evidence
The interesting boundary is between obtaining the information and applying the organization's decision criteria to it.
Institutional knowledge is not necessarily institutional judgment
RealPage describes part of its new architecture as "institutional intelligence."
The platform builds on a governed knowledge graph so its agents and analytics operate from a consistent understanding of the real-estate domain.
That solves an important problem.
An enterprise agent should not reconstruct the organization from random documents every time it receives a request.
But knowing the organization's facts and relationships is not quite the same thing as knowing how the organization makes a decision.
Suppose the system knows that a property has exceeded its maintenance budget.
That is knowledge.
Suppose it also knows that a particular repair is safety-critical, that emergency work below one threshold may proceed automatically, and that anything above another threshold requires regional approval.
That begins to look like judgment.
The distinction matters because the two things may have different owners and different change cycles.
Data teams may own the knowledge graph.
Security teams may own tool authorization.
Business or risk owners may own the decision criteria.
Agents use all three.
This is the boundary I am exploring with Judgment Pack
The Judgment Pack Specification is an attempt to make the third category explicit.
A Judgment Pack can define what evidence matters, how evidence is interpreted, which rules and exceptions apply, how missing information is handled, and which dispositions are possible.
Conceptually:
organizational knowledge
|
v
evidence
|
v
judgment
|
v
disposition
|
v
execution policy
|
v
action
The model does not disappear from this architecture.
It can gather evidence, interpret requests, call tools, plan workflows, and interact with people.
The difference is that changing the model does not automatically change the organization's definition of the correct decision.
That property becomes more interesting when a model like Muse Glimmer can run locally.
A company might use a frontier model for one workflow, a local model for another, and a specialized model for a third.
Should each model independently reconstruct the company's decision logic?
Or should they operate against the same reviewed judgment artifact?
That is something we can test.
The safety research is moving toward similar distinctions
The SafeAI workshop at UAI 2026 published its accepted program today.
Several of the papers sit surprisingly close to this problem.
There is work on auditable agent memory, authority-bearing tool parameters, system assurance, abstention, and a paper titled "Underspecified, Not Uncertain: Context Ambiguity Versus Knowledge Gaps in Safety-Critical LLM Use."
I find that last distinction particularly useful.
There are at least two reasons an agent may not be able to make a reliable decision.
The model may be uncertain.
Or the decision itself may be underspecified because a required fact is missing.
Those should not automatically produce the same behavior.
If the system has not completed a sanctions check, switching to a larger model does not create the missing evidence.
The correct response may simply be:
cannot decide yet
This is one reason I think explicit evidence requirements matter.
Generating possibilities is getting easier
A different example appeared today in scientific AI.
Discovered Materials raised a $9 million seed round to use swarms of agents to search for new semiconductor materials.
Its agents can generate thousands of candidates, which are then filtered using physics simulations and eventually laboratory validation.
One investor involved in the round made an interesting observation: generating candidates may no longer be the bottleneck. Filtering and synthesizing the right candidates is.
I would not equate scientific validation with enterprise judgment.
But there is a shared pattern.
Better models make candidate generation cheaper.
Agents can produce more recommendations, plans, actions, vendors, hypotheses, and possible answers than people could manually create.
That increases the importance of selection.
What evidence makes one candidate acceptable?
Which criteria eliminate another?
When should the system abstain?
Who owns those criteria?
How do they change without allowing the agent to rewrite its own judge?
A small experiment could make this concrete
Muse Glimmer creates a useful opportunity to test the architecture rather than debate it.
Take one existing enterprise workflow.
Run it with a local Muse Glimmer agent.
Run the same workflow with a frontier cloud model.
Let both agents gather the evidence.
Keep the Judgment Pack and evaluator unchanged.
Then compare what changes.
If model capability changes the quality of evidence acquisition but not the organization's final decision semantics, that would support a meaningful separation between agent intelligence and organizational judgment.
If it does not, that would be equally useful to learn.
As agent models become cheaper, smaller, and easier to swap, I think the durable parts of an enterprise AI architecture will become easier to identify.
The question is whether organizational judgment is one of them.
Top comments (1)
I think judgment needs to live in the workflow boundary, not only in the model prompt. If the agent can run anywhere, the organization still needs durable rules for approvals, evidence, rollback, and what the agent is never allowed to decide alone.