Sarah Santiago on why enterprise AI architecture should begin with the work that needs to be done, not the models and agents available to do it.
The starting point for enterprise AI has become remarkably predictable: choose a model, connect enterprise data, introduce agents and identify workflows they can automate.
It is a logical technology-led approach. It is also one that risks putting the most important architectural decisions at the end of the process.
Because enterprise work does not begin with intelligence. It begins with business relationships, obligations, decisions, responsibilities and outcomes. The technology must operate within that structure, not define it after the fact.
Consider a contractual exception. Before an AI agent can resolve it, the enterprise must establish which agreement applies, how the relevant obligations relate to current policy, who holds approval authority and what constitutes successful resolution. These are not implementation details to address once the agent is built. They determine what the agent needs to understand and what it can legitimately do.
The fundamental mistake is treating enterprise execution as something that follows AI capability, rather than something that should shape its architecture from the beginning.
This changes where enterprises should start, how they represent business knowledge and what they expect from Systems of Work.
Start with the work, not the intelligence
Most enterprises already possess considerable knowledge about how they operate. It is distributed across CRM platforms, ERP systems, contracts, policies, process definitions and the experience of employees.
These sources were developed for different purposes. A customer may be represented as a commercial account in one system, a contracting entity in another and a billing relationship in a third.
Retrieving these records does not automatically establish how they relate.
Retrieval-augmented generation can locate relevant information and help models use it in their responses. But retrieval alone does not establish whether two records refer to the same legal entity, which obligation takes precedence or which approval is required for a particular exception.
These questions require business-specific context.
An ontology defines the concepts and relationships relevant to a domain. A knowledge graph can represent particular entities and their relationships using that structure. Together, they provide a means of making business context explicit rather than relying entirely on what a model can infer from disconnected information.
But the architectural question is not how much enterprise knowledge can be represented.
It is which knowledge must be represented to support a particular decision and the work that follows it.
For a contractual exception, that might include the relationship between customer, legal entity, agreement, obligation, amendment, approval role and operational record.
Beginning with the work gives the ontology a practical boundary. It also prevents knowledge modelling from becoming an expansive exercise disconnected from operational value.
A knowledge graph is not an execution architecture
There is a second assumption worth challenging: once enterprise knowledge is connected and accessible to AI, intelligent execution will naturally follow.
A knowledge graph can establish that an obligation exists and identify the role authorised to approve an exception. It does not, by itself, determine whether approval should be granted, enforce the decision or update the systems affected by it.
These responsibilities belong to different architectural capabilities.
- Business context establishes the meaning of relevant entities, relationships and obligations through ontologies and knowledge graphs.
- Reasoning helps interpret the situation, assess evidence and propose appropriate actions.
- Decision controls apply business rules, permissions and approval requirements to determine which actions are authorised.
- Execution uses workflows and enterprise integrations to perform those actions in the relevant systems.
- Operational evidence records decisions, verifies state changes and establishes whether the intended outcome was achieved.
The distinction is important because these capabilities cannot substitute for one another.
A language model can recommend an action without having the authority to execute it. An ontology can describe an approval requirement without enforcing it. A workflow engine can perform a transaction without independently determining whether that transaction is appropriate.
Reliable execution depends on how these components are connected, particularly when records conflict, information is incomplete or a process encounters an exception.
This is where Systems of Work become architecturally significant.
Systems of Record preserve the information and transactions on which enterprises depend. A System of Work connects business context, intelligence, people, decision controls and execution around a defined operational outcome.
Its purpose is not to replace every underlying enterprise application. It is to coordinate how work moves across them, ensuring that decisions can be translated into authorised actions and that outcomes can be verified.
The architecture must therefore be designed around the complete path from understanding to execution, rather than treating agents as independent automations attached to existing systems.
Let execution define what the architecture needs to know
A work-first approach changes the sequence of implementation.
Instead of beginning with a comprehensive enterprise ontology or a collection of agents, begin by defining the outcome and tracing the decisions necessary to achieve it.
For a contractual exception, the enterprise would identify the relevant business entities, applicable policies, approval boundaries, required system updates and evidence needed to confirm resolution.
Those requirements determine which relationships the ontology must represent, which reasoning capabilities are useful, which decisions require deterministic controls and where human involvement remains necessary.
They also define what successful execution means.
An agent that interprets a contract correctly but fails to update the operational record has not completed the work. Neither has one that performs the update without obtaining the required approval.
This is why outcome verification must be designed into the architecture from the outset.
At ConceptVines, this work-first thinking informs the use of domain-specific ontologies and knowledge graphs alongside reasoning, agents, enterprise integrations and governance to develop Systems of Work.
The resulting architecture must also evolve through operational experience. Exceptions expose missing relationships. Failed hand-offs reveal unclear responsibilities. Policy changes require updates to both business representations and enforcement mechanisms.
Starting with a defined body of work allows enterprises to improve these capabilities incrementally, rather than attempting to model every aspect of the organisation before delivering value.
Over time, reusable business concepts, integration patterns and decision controls can support additional Systems of Work across functions.
The larger opportunity is to make enterprise knowledge operational: available where decisions are made, connected to the authority required to act and accountable to the outcomes produced.
Models will improve. Agents will become more capable. Enterprise data will become increasingly accessible. None of these developments eliminates the need to define how the business itself operates.
The enterprise should not have to reorganise its understanding of work around what an AI model can do. Its AI architecture should be built around what the business needs to accomplish.
That is the difference between deploying intelligence into an enterprise and building an enterprise capable of putting intelligence to work.