Giving agents a model of the world
5 min read
Imagine asking an agent to help plan dinner for six friends on Friday. Ana is vegetarian. Your brother is bringing dessert. You want a menu and a shopping list.
Then Ana says she cannot come, your brother asks to bring his partner, and everyone agrees to move dinner to Saturday. You ask the agent to update the plan.
The number of guests might stay the same, but the plan needs another look. Ana's dietary preference belongs to her. Your brother's offer to bring dessert belongs to this dinner, and it is worth checking whether it still holds for Saturday. His partner's preferences are still unknown.
For a dinner, those relationships can stay implicit. I would expect a capable model to work much of this out from the conversation, without someone defining a dinner ontology first. If it helps with these plans regularly, it should carry forward the right details, however it represents them.
What belongs to the person, and what belongs to the plan?
Remembering "vegetarian dinner for six on Friday" compresses several things into one note. It loses who is vegetarian, which six people were coming, and whether Friday was a fixed commitment or an early suggestion.
Ontology makes those distinctions explicit: what things exist, how they relate, and which constraints apply. Giancarlo Guizzardi and colleagues' work distinguishes entities from the roles they can hold. Someone hosts this dinner and attends another as a guest. Their dietary preference may remain relevant across both; their offer to bring dessert usually does not.
Moving dinner to Saturday should keep its invitations and menu attached to the same event. Planning another dinner next month should create a new event, without assuming the same people have accepted or offered to cook.
What counts as one customer?
A company has its own versions of this ambiguity. Consider a hypothetical distributor whose sales team talks about Acme as one customer. Acme North and Acme South are separate legal entities with separate contracts.
The commercial owner approves a discount for invoices issued under Contract N during August. An agent receives two August invoices, N-104 and S-208, both carrying the Acme brand. Its job is to identify which invoice this approval covers.
The agent needs to connect each invoice to its contract and check the approval's contract and date restrictions. N-104 belongs to Contract N. S-208 belongs to Contract S.
The shared brand explains why the records appear together. The contract relationship explains why only one invoice falls within this approval.
Each entity holds its own contract. Each invoice is issued under that contract. Sharing a group does not extend the approval.
Sales can be right to manage Acme as one relationship while billing is right to keep the legal entities separate. I would want the agent to preserve both views. A question about total business with Acme could include both entities. A question about this discount has to follow the specific agreement. Forcing everyone to use one flat definition of customer would make one of those jobs harder.
What the model cannot infer
A model may already understand what a customer, an invoice, or an approval usually means. Those words alone do not tell it whether this distributor uses customer to mean a group or a contracting entity. The business has to supply that distinction, through context, existing records, or an explicit ontology. The actual contracts and approvals still need evidence.
Much of this may already be expressed in the software. A calendar connects an invitation to an event and records a response. Billing connects an invoice to an agreement. I would start by using those relationships.
I would be more inclined to preserve relationships explicitly when several tools use them, the same ambiguity keeps causing mistakes, or a mistake is costly. Even then, the existing billing records might already provide the structure we need.
An agent can help infer missing links and ask about conflicts. Someone still needs to settle a disputed approval or business definition. We can represent the result with tables, typed relationships, and rules. A diagram can make those relationships easier for a person to inspect, even when the agent works from messages or existing records. Drawing a graph does not establish that an invoice belongs to a particular contract.
Follow what would change
Back at the dinner, Ana leaving does not automatically mean we should remove every vegetarian dish. We might like the menu as it is, or someone else might prefer it. The agent can identify which reason changed without deciding that every earlier choice must change with it.
Your brother's partner still has unknown preferences. If your brother confirms dessert for Saturday, the shopping list should not add ingredients for a second one. The agent needs the current replies to update the plan; a relationship alone cannot establish what anyone has agreed to do.
What I would expect it to learn
Suppose I correct the agent because it keeps marking everyone from the previous dinner as confirmed for the next one. Saving this week's guest list would fix the current plan. It would leave the habit of treating previous attendance as a new acceptance unresolved.
If invitations are already tied to events, the agent may be using those records badly. If the software only stores a permanent list called "dinner guests," it may need a way to record attendance for each event. I would locate the failure before adding more structure.
Fixing the recurring mistake should change how it handles the next invitation list. Changes to a shared rule or data model deserve checks against earlier cases too. For Acme, separating the customer group from the contracting entities should preserve the sales view while fixing the invoice check. Someone who understands the agreements should review the effect on existing decisions.
I would also want enough history to explain a change. The original menu may have made sense for the original guests. Updating Saturday's plan should not make the agent describe its earlier suggestion as a mistake merely because someone later canceled.
For Saturday, I would want the agent to keep the dishes we still want, update the guest list, and flag the two things we have not confirmed: whether my brother is still bringing dessert and whether the menu works for his partner. I can answer those without explaining the whole dinner again.