Context Ontology Services That Teach AI How Your Business Works

Context Ontology
Enterprise Context Layer
Knowledge Graph Implementation
Context Ontology Accelerator
AWS Context

Mactores context ontology services turn scattered data, documents, systems and business rules into one governed model that AI agents read before they answer: what each term means, how customers, products, contracts and assets relate, which rules apply, and what an agent may do next. We build it with your experts and run it on the Context Ontology Accelerator today, on AWS Context when it becomes available, or on the context layer your data already uses, with the production date and fee fixed in the SOW.

Most organizations don't lack data. They lack a shared, machine-readable account of what their data means. Ask an agent whether an order can ship today and it will find the order, the stock count and the customer record, then say yes without knowing that the stock is promised to a priority account or that the customer is past its credit limit. Nothing in the data was wrong. The meaning was missing, and that gap is where confident wrong answers come from.

Start with one answer your team no longer trusts

Bring the question and what your agent said.

The first session shows what was missing, what a first release covers and when it can go live.

Book a scoping call

AWS Partner Tier: Premier Tier
AWS Specialization: Agentic AI
AWS service validations: 17
AWS-certified practitioners: 200+

94%

delivery record against committed dates, counting on-time and early finishes

12 weeks

from kickoff to a production claims agent on regulated data at KlearTrust

80%

of KlearTrust claims now clear within the agent's approved authority

AWS service validations across data, AI and infrastructure services

2008

building on AWS since

Top Mactores Clients

All 21 case studies →

Customers include Safaricom, Synaptics, Flipboard, Poshmark, Seagate, HP, Adani, DocuSign, KlearTrust, Tilia, Sterne Kessler and Total Expert.

What Are Context Ontology Services?

Context ontology services design, build and run the model that tells AI what your business means. Mactores maps your entities, relationships, definitions and rules, connects them to the systems that hold the evidence, sets who and what may use each part, and serves the result to agents, analytics and applications as a governed context layer.

Think of it as institutional memory your AI can query. Retrieval can hand an agent the right paragraph. It can't tell the agent which definition of a customer finance uses, which system wins when two records disagree, or whether the agent may act on what it found. A context ontology holds those answers as verified relationships, constraints, owners, lineage and decision rights, and our guide to what context ontology is explains the idea from first principles.

A useful enterprise ontology answers questions like these:

What qualifies as an active customer, an eligible claim, an approved supplier or a billable asset?
Which system is the source of truth for a customer record, a product specification or a contract term?
Which data can an agent read, change, approve or escalate?
Which policies, jurisdictions, entitlements and approval thresholds apply to a decision?
How does a change to a product, contract, regulation or reporting line ripple across systems?
How can a reviewer prove why an AI system made a recommendation or took an action?

Two kinds of context matter, and most programs only capture the first. Descriptive context explains what something is: a product hierarchy, a customer segment, a plant. Operational context decides what may happen: the rule that blocks an unauthorized discount, an out-of-network claim approval or an unapproved data export. Agents need both, and the second is where the business risk sits.

Why Do AI Agents Give Confident Answers That Are Wrong for Your Business?

AI agents give confident wrong answers because they reach your data but not its meaning. They see tables, documents and API responses, yet not what an active customer means in your company, how a part relates to an order, or which policy applies next. A context ontology supplies those definitions, relationships and rules at answer time.

The problem is rarely a missing model. It is missing context, and it shows up as soon as agents move from demos to real work. McKinsey’s State of AI 2026 found that 40% of respondents from large organizations report scaling AI agents in at least one function, up from 27% a year earlier, yet only about two in ten have reached the scaling phase across the organization. That gap between trying agents and trusting them is usually a context problem: entity resolution, policy boundaries, source-of-truth rules and auditable action paths that nobody wrote down, or that live only in people’s heads.

When VentureBeat asked 130 organizations in its VB Pulse survey in August 2026 where wrong answers came from, the pattern was clear:

64%

traced at least one confident but wrong agent answer to missing or inconsistent business context in the previous six months.

32%

relied mainly on retrieval over documents or a vector index to give their agents context.

13%

named a governed semantic layer or ontology as their agents’ main source of context.

The costs land in the same six places in almost every enterprise we work with:

Business problem

What usually happens today

What a context ontology changes

Inconsistent definitions

What usually happens today: Sales, finance, operations and data teams calculate the same metric differently

What a context ontology changes: One governed definition per entity and metric, resolved before any agent answers

Unsafe agents

What usually happens today: Agents retrieve plausible content but have no authority boundaries

What a context ontology changes: Policies, entitlements and action limits become checks the agent can’t skip

Weak retrieval

What usually happens today: Search returns similar documents, not answers a decision can rest on

What a context ontology changes: A knowledge graph links entities, relationships and evidence across systems

Compliance exposure

What usually happens today: Policies live in PDFs, tickets and people’s heads

What a context ontology changes: Rules become versioned, testable and traceable to sources and decisions

Integration debt

What usually happens today: Every new system needs its own mapping and reconciliation

What a context ontology changes: One shared model cuts mapping effort and makes lineage visible

Slow AI delivery

What usually happens today: Every use case starts with a fresh data investigation

What a context ontology changes: Reusable context shortens the path for each new agent, RAG or analytics use case

The payoff isn't a prettier data model. It is fewer wrong decisions, faster root cause analysis, safer automation and a foundation you don't rebuild for every new use case. That shared foundation is what people now call an enterprise context layer, and the ontology is the model at its center.

Agent answering confidently, and wrongly?

Send three of its answers. We’ll show which definitions and rules it was missing.

An answer review traces each miss to the context behind it.

Get an answer review

What Do Mactores’ Context Ontology Services Include?

Seven services, run as one program: context discovery, ontology design, knowledge graph implementation, a governed semantic layer, AI and agent integration, governance and lineage, and validation and cutover. Each one ends in something you can test, and everything ships in open formats inside your own accounts, ready for your team to run and extend.

You get a working context layer, not a slide deck of conceptual boxes. Scope starts from the decisions that carry commercial or regulatory weight: we ask which 10 to 20 questions your agents must get right, then build the part of the ontology those questions need. That keeps the first release small enough to finish and gives the knowledge graph implementation a clear finish line. If you’re still choosing which AI use cases to fund, generative AI consulting is the better starting point, and ontology work begins once the questions are clear.

Service

What we deliver

What changes for you

Context discovery

What we deliver: Interviews, system analysis, data profiling, process mapping and rule extraction

What changes for you: A ranked map of entities, decisions, systems and high-risk ambiguities

Ontology design

What we deliver: Entity models, relationships, attributes, taxonomies and controlled vocabularies, at enterprise and domain level

What changes for you: One shared language for data, applications and AI

Knowledge graph implementation

What we deliver: Graph schema, ingestion, entity resolution, relationship extraction and graph storage

What changes for you: Connected context you can query across systems

Semantic layer

What we deliver: Business definitions, metrics, dimensions, access rules and governed data products

What changes for you: The same answer in BI, applications and agents

AI and agent integration

What we deliver: Retrieval design, graph-enhanced RAG, agent tool schemas, MCP integration and guardrails

What changes for you: Agents grounded in approved context

Governance and lineage

What we deliver: Owners, stewards, data contracts, quality rules, lineage, versioning and audit trails

What changes for you: Decisions you can defend and changes you control

Validation and cutover

What we deliver: Test harnesses, golden questions, regression tests, acceptance criteria and runbooks

What changes for you: Go-live decided by evidence, not by guesswork

Every engagement ships with:

A context ontology in production, in your own AWS account or on the platform you chose
The ontology, mappings and rules in open, exportable formats, including W3C OWL, SHACL and R2RML where the platform supports them, under version control
A golden-question test set with baseline and post-launch accuracy
Named stewards for every definition and an approval workflow for changes
Access policies your security team has reviewed and tested
Runbooks, a pinned release with an upgrade path, and training for your stewards

Drafted by AI

Candidate entities and relationships from schemas and documents
Term and synonym matching across systems
Draft rules extracted from policies and manuals
Mappings from the ontology to source tables
Test questions and regression runs on every change

Decided by people

What a term means when two teams disagree
Which rules are binding and which are guidance
Which source wins when systems conflict
Who may see what
When an answer is good enough to go live

That split is why ontology work no longer takes the months it once did. AWS says the Context Ontology Accelerator turns months of manual ontology authoring into days. The time saved goes into the work no tool can do for you, such as getting finance and sales to agree on what a booked order is.

Pick your first ten questions

They define the first release, its test set and its finish line.

One session with an FDE turns them into a first-release scope.

Scope my first release

Which Platform Should Hold Your Ontology: the Context Ontology Accelerator, AWS Context or Another Context Layer?

Choose the platform where your data, agents and governance already live. On AWS, the open-source Context Ontology Accelerator is generally available now, and AWS says its ontologies carry into AWS Context, announced in June 2026 with no availability date yet. Databricks, Microsoft, Snowflake and Palantir each offer their own context layer.

On AWS there are two routes today. The Context Ontology Accelerator, released under Apache 2.0 on 31 July 2026, drafts an ontology from structured and unstructured data for your experts to review, stores the approved model in a knowledge graph you own, and serves it to any agent through its included MCP server. AWS Context, the managed knowledge graph AWS announced at its New York summit, is still listed as coming soon. Every other major data platform shipped or announced a context layer in 2026 as well. The table shows where each one stood when we last checked, in November 2026, with the AWS knowledge graph options first because Mactores is an AWS Premier Tier Services Partner.

Platform

What it is

Status

Fits when

Context Ontology Accelerator (AWS)

What it is: Open-source accelerator that drafts an ontology for expert review, stores it as a knowledge graph and serves it to agents over MCP

Status: Generally available since 31 July 2026; self-managed

Fits when: Your data is on AWS and you want to start now, with full control of the stack

AWS Context (AWS)

What it is: Managed knowledge graph that infers how your data relates; stewards review and promote relationships; queries inherit IAM and AWS Lake Formation permissions

Status: Announced 17 June 2026; coming soon, with no preview or general availability date

Fits when: You want a managed service on AWS and can start on the accelerator in the meantime

Genie Ontology (Databricks)

What it is: Context layer that gives Genie agents a business-aware map built on Unity Catalog semantics, metric definitions and rules

Status: Public preview

Fits when: Your data and agents run on Databricks

Fabric IQ (Microsoft)

What it is: Business-context layer over Fabric and OneLake that combines an ontology, Power BI semantic models and a graph

Status: Ontology in preview; parts of Fabric IQ generally available

Fits when: Your analytics run on Microsoft Fabric and Power BI

Horizon Context and Cortex Sense (Snowflake)

What it is: A governed store for definitions and metrics, plus a runtime layer that learns context from query history for Cortex agents

Status: Preview

Fits when: Your data and agents run on Snowflake

Ontology (Palantir)

What it is: The ontology at the core of Foundry and AIP

Status: Established

Fits when: You already run Foundry or AIP

The platform matters less than most comparisons suggest. The costly work is the same on all of them: agreeing what each term means, deciding which source wins, and writing rules down so a machine can check them. Captured in open formats, that work moves with you, which is why we keep the ontology portable and in your accounts. Our side-by-side review of where business context should live goes platform by platform, from AWS to Palantir.

Should You Wait for AWS Context?

No. AWS says ontologies built with the accelerator can be used and managed in AWS Context, where managed, user-defined ontologies will become a native feature. The definitions your experts agree, the sources you map and the questions you test are the slow part, and none of that is lost when the managed service arrives. Teams that start now reach launch day with a working ontology instead of a plan. We track what has been announced, and what is still unknown, in our running briefing on AWS Context.

What Does the Accelerator Leave to You?

The model itself. No industry ontologies ship with it, so your entities, relationships and definitions still have to be decided.

The rules. Policies, limits and specifications have to be found, written as checks and approved by the people who own them.

Production operations. You deploy and run it yourself, pin releases, plan upgrades and carry on-call. Its GitHub repository is a read-only mirror that takes issues but not pull requests.

Run cost. It runs on Neptune for the graph, OpenSearch Serverless for search and Bedrock for models, all in your account, so query routing and guardrails decide the monthly bill.

Which AWS Services and Tools Sit Underneath?

We are neutral on tools where the architecture calls for it, and we build AWS-first. The right stack depends on your estate, latency needs, data volumes, security posture and the skills of the team that will run it.

Layer

Common choices

When it earns its place

Graph storage

Common choices: Amazon Neptune, Neo4j

When it earns its place: Relationships, traversals and impact analysis are central to the questions

Semantic layer

Common choices: dbt, Cube, AtScale, Amazon Redshift

When it earns its place: Consistent metrics and governed definitions for BI and agents matter most

Data platform

Common choices: Amazon S3, AWS Glue, Amazon Redshift, Amazon Athena, Amazon EMR

When it earns its place: The ontology has to work across large, multi-source data

Retrieval

Common choices: Amazon OpenSearch Service, Amazon Bedrock Knowledge Bases, pgvector

When it earns its place: Unstructured content has to be found alongside structured context

Agents

Common choices: Amazon Bedrock AgentCore, Amazon Bedrock, MCP servers

When it earns its place: Agents need tools, policies, memory and governed action paths

Governance

Common choices: AWS Lake Formation, Amazon SageMaker Catalog, Collibra, Microsoft Purview

When it earns its place: Ownership, lineage, access and policy enforcement can’t be optional

We don’t force a graph database into every problem. Sometimes a well-governed semantic layer and catalog are enough. Sometimes graph-enhanced retrieval is the difference between an AI system that guesses and one that can explain its answer.

Not sure which platform fits?

Bring your data and agent stack. We’ll map each option against it in one session.

Accelerator, AWS Context, or the context layer you already run.

Compare platforms for my stack

How Does a Context Ontology Engagement Run, From First Decision to Production?

A Mactores context ontology engagement runs in five phases: context and decision discovery, ontology and semantic modeling, knowledge graph and data integration, agent and application integration, then validation and handoff. Each phase ends with a signed exit, and nothing goes live until golden questions pass, access policies are tested and every definition has a named steward.

The approach is deliberately incremental. We don’t ask you to model the whole enterprise before proving value. We pick one high-value decision domain, build its semantic foundation, connect the systems it needs and put it into production with measurable controls. The phases follow how Mactores works on every engagement.

01

Phase 01

Context and decision discovery

What happens

Business owners, stewards and security leads name the decisions that matter; systems of record, approval paths, exceptions and unwritten rules are mapped; the production date is set

Owner

Shared

Signed exit

Ranked context map signed and SOW countersigned
02

Phase 02

Ontology and semantic modeling

What happens

Entities, relationships, hierarchies, definitions, metrics, policies and constraints drafted by AI, then reviewed with your domain experts

Owner

Agents and FDEs

Signed exit

Business owners approve definitions and rules
03

Phase 03

Knowledge graph and data integration

What happens

The ontology implemented on your chosen platform, with ingestion and sync, entity resolution and lineage from source to consumer; systems of record stay in place

Owner

Agents and FDEs

Signed exit

Sources connected and reconciled in a test environment
04

Phase 04

Agent and application integration

What happens

The ontology connected to retrieval, agents, analytics and workflows, with tool schemas, permission boundaries, approval thresholds and audit requirements

Owner

FDEs and your teams

Signed exit

Integration acceptance passed
05

Phase 05

Validation, governance and handoff

What happens

Real scenarios and edge cases tested, stewardship and change control set up, monitoring live, runbooks handed over

Owner

Shared

Signed exit

Customer-signed acceptance

The go-live checklist every ontology passes:

01
Every term in scope has one definition and a named owner
02
Golden questions pass at the accuracy threshold agreed during discovery
03
Governed metrics match the report of record
04
Every rule returns a clear pass or fail, with the reason
05
Access policies are tested for each role, including the cases that must be denied
06
Every answer records the definitions, sources and ontology version it used
07
Stewards can propose, review and publish changes through the workflow
08
The platform release is pinned and the upgrade path documented
09
Cost guardrails are set for query and model usage
10
An on-call owner is named and the runbook handed over

Once discovery closes, the SOW fixes scope, fee and production date. If a delay is ours, so are the extra hours. If it starts on your side, such as a definition owner missing at a phase exit, extra hours bill at the time-and-materials rate named in that same SOW. Our delivery commitment sets out the full terms.

Start with discovery

Discovery ends with a signed context map and a production date.

Everything after that runs against those signatures.

Book the discovery session

How Is Context Governed, Secured and Audited Once Agents Rely on It?

A context ontology is governed like code and approved like policy. Named stewards own each definition, every change is proposed, reviewed and published as a new version, and access policies apply on every query path. Each agent answer records the definitions, sources, rules and ontology version behind it, so anyone can retrace it later.

Context ontologies often touch sensitive customer, employee, financial, clinical, operational or intellectual-property data. We design for least privilege, data minimization, lineage and controlled access from the first week, because the gap is real: IBM’s Cost of a Data Breach Report 2026 found that 68% of breached organizations had no AI governance policies, up from 63% a year earlier, and 92% of those with an AI-related incident lacked proper AI access controls.

Ownership.
A named steward for every term and metric, a designated source of truth for every entity, and disputes settled by a named business owner rather than by the data team.
Change control.
Proposals, impact analysis, reviews and releases in a versioned workflow, golden questions run on every release, and rollback to any earlier version.
Access.
Role- and attribute-based policies applied on every answer path, from governed metrics to graph queries to document search, with classification, masking, tokenization and residency controls where required. On AWS they work alongside IAM and AWS Lake Formation, and the accelerator adds Cedar authorization and a SQL firewall.
Evidence.
Lineage from source systems through ontology objects to AI output, plus audit trails for retrieval, tool calls, agent actions, approvals and policy exceptions.

These controls line up with the NIST AI Risk Management Framework, including its Generative AI Profile, which names 12 risks that generative AI creates or makes worse and suggests actions for each. An ontology that can’t enforce access, lineage and approval boundaries isn’t ready to sit under enterprise agents.

What an auditor asks

Where the answer comes from

Who approved this definition, and when?

Where the answer comes from: The stewardship log for that term

Which version was live when the agent answered?

Where the answer comes from: The answer trace, linked to the ontology release

Could the agent see data it shouldn’t?

Where the answer comes from: Access policy tests for each role, and the query logs

Why did the agent give this answer?

Where the answer comes from: The trace of definitions, sources, rule checks and the path taken

What changed since last quarter?

Where the answer comes from: The version diff between releases

This is the context side of AI agent governance. The agent side, covering permissions, approvals and hand-offs to people, is part of our AI agent development services.

Bring your audit questions

We’ll show how each one is answered from the ontology’s own records.

Stewardship logs, answer traces, access tests and version diffs.

Review my governance model

Which Industries Need Context Ontology First, and for Which Questions?

Context ontology pays off first where one word means different things in different systems and a wrong answer is costly: supply chain in manufacturing, transactions in financial services, patients and providers in healthcare, product metrics in software, and network-to-customer links in telecom and media. Each starts with the questions its agents miss most.

Every industry has a word that means three things depending on who you ask. That word is usually where the first release starts, and each industry below has its own page on how we approach it.

Manufacturing

Supply chain AI that knows where material sits, what is in transit, which orders a late part puts at risk and which supplier can cover it. The first release reconciles part, location and supplier identities across ERP, MES and warehouse systems, then adds the rules for quality holds, allocation and approved sources. Product genealogy and one OEE definition across plants follow on the same model. Planners get one answer to a shortage question instead of four spreadsheets that disagree.

Context ontology for manufacturing

Financial Services

A transaction ontology that links accounts, parties, merchants, counterparties and products, so AML, fraud, disputes and payments agents see what a transaction means and every alert can be retraced. Ownership chains, product rules and entitlements sit in the model, which lets an examiner follow an agent's answer back to the data and policy behind it rather than to a prompt. Banks and insurers usually start with transaction monitoring, disputes and exposure questions, where definitions drift most.

Context ontology for financial services

Healthcare and Life Sciences

One model of patient, care episode, provider, network, payer and measure, so care coordination, provider data and quality reporting agents give answers that reconcile, with PHI access set by policy. Member, subscriber and patient stop meaning three different things across eligibility, claims and clinical systems, and quality counts come back the same every time they're asked. Payers often begin with prior authorization and provider directory questions, and providers with quality reporting and care coordination.

Context ontology for healthcare

Internet and Software

One definition of ARR, seats and entitlements for your product's agents, and for customers' agents that call your product as a tool over MCP, with tenants kept apart by policy. CRM, billing and product analytics stop disagreeing about revenue, and the product becomes something other agents can rely on rather than something they route around. Product, finance and customer success teams finally quote the same numbers to the board and to customers alike.

Context ontology for software

Telco, Media, Entertainment, Gaming, and Sports (TMEGS)

Agents that trace a network alarm to the services, customers and SLAs behind it, and check content rights by title, territory and window before anything streams. Network and billing systems mean different things by a service, so the ontology joins them, while customer data and children's data stay behind rules the agents can't bypass on a busy night. Operators usually start with network-to-SLA questions, and media teams with rights and windows.

Context ontology for telecom and media

Scoped to your sector

Your terms, your systems, your regulators.

Talk to the industry lead who has modeled context in your sector.

Talk to an industry lead

What Drives the Cost of a Context Ontology Engagement?

The cost depends on how many business questions and domains are in scope, how many source systems feed them, how far teams disagree on definitions, the number of rules to encode, and your compliance scope. A narrow domain ships as a focused first release, while a multi-domain ontology follows a phased roadmap. Mactores fixes the fee and date after discovery.

Pricing note

Ontology work has no list price, because the effort sits in your definitions and rules rather than in the software. The drivers below shape the fee, and the binding figures appear only in your signed SOW.

A narrow domain such as customer 360, product master data, claims adjudication or supplier onboarding usually makes a good first release. The table shows what moves the effort from there.

Cost driver

Why it changes the effort

Questions and domains in the first release

Why it changes the effort: Each question pulls in the entities, definitions and rules it needs

Number and complexity of source systems

Why it changes the effort: More systems mean more mapping and more naming conflicts to settle

State of existing metadata

Why it changes the effort: Weak catalogs and thin documentation push more work into discovery

Entity resolution

Why it changes the effort: Duplicates and conflicting records across systems need matching rules and owner sign-off

Rules and unstructured content

Why it changes the effort: Policies, contracts and manuals need extraction and review before their rules exist

Security, residency and regulation

Why it changes the effort: Regulated data adds policy design, testing and audit evidence

Agents and applications consuming it

Why it changes the effort: Each consumer adds integration, testing and access design

Platform and ongoing stewardship

Why it changes the effort: Self-managed and managed context layers differ in setup, hardening and handover work

Run cost. After go-live, the monthly bill comes from graph, search and model usage on the platform you chose. Routing makes the difference: on the accelerator, a question that matches a governed metric is answered without a model call, so the more of your common questions resolve that way, the lower the bill. Cost guardrails and reporting your finance team can read are set before launch.

Scope the first release

Your questions and sources, one fixed fee and one date.

Quoted after discovery, binding in the SOW.

Get my fixed quote

How Is Mactores’ Approach Different From a Typical Ontology Project?

Many firms can draw an ontology. Fewer can make one work inside a regulated, fast-changing enterprise. Mactores starts from the decisions that carry risk, ships a context layer in production rather than diagrams, designs agent controls in from day one, and commits to a fixed date and fee with customer-signed acceptance at each phase.

Dimension

Typical ontology project

Mactores context ontology delivery

Starting point

Typical ontology project: Broad conceptual modeling

Mactores context ontology delivery: High-value decisions, systems and risks

Output

Typical ontology project: Diagrams, spreadsheets and recommendations

Mactores context ontology delivery: A context layer in production, with integrations, tests and runbooks

AI readiness

Typical ontology project: Often left for a later phase

Mactores context ontology delivery: Retrieval, agents, guardrails and auditability designed in from the first week

Commercial model

Typical ontology project: Open-ended consulting

Mactores context ontology delivery: Fixed date and fixed fee, with customer-signed acceptance

Build depth

Typical ontology project: Strategy-led

Mactores context ontology delivery: AWS architecture, data integration, security and cutover

Governance

Typical ontology project: Policy documents

Mactores context ontology delivery: Access, lineage, quality and approval controls that are enforced

Change

Typical ontology project: A static model

Mactores context ontology delivery: A versioned ontology with stewards and an operational owner

Mactores is the agent-native AWS modernization firm. Agents carry the repeatable volume of an engagement: discovery, schema mapping, dependency analysis, validation harnesses and test generation. FDEs own the architecture, the security posture, the judgment calls and the delivery commitment. Ontology programs fail when they stay theoretical, and they succeed when the model is wired to real systems, tested against real decisions and kept current through real change.

Ownership is part of the design, too. Gartner predicts that by 2028, up to 70% of enterprises will abandon agentic AI built through vendor forward-deployed models, largely because internal teams can’t maintain it once the vendor leaves, and it advises buyers to settle IP ownership, knowledge transfer and an exit plan from day one. Our SOWs do exactly that: the ontology lives in your accounts in open W3C formats, stewards are trained before handover, and the exit terms are signed before work starts.

What Results Should You Expect From the First Domain?

Results depend on your starting point, but a well-built context ontology should change these things within its first production domain:

Faster, more consistent answers across customer service, operations, finance and compliance work
Less time spent reconciling conflicting definitions, reports and extracts
Safer agent deployment, through explicit permissions, approval paths and audit trails
Better retrieval, because answers draw on connected context rather than isolated document chunks
Faster starts for new AI use cases, because core entities, policies and lineage already exist
More confidence among risk, legal, security and audit stakeholders

We won’t promise that an ontology fixes every data problem. We do commit to a disciplined path from ambiguity to a context layer your teams can use, extend and defend.

The delivery model in full

See how agents and FDEs split the work, phase by phase.

The same model runs every Mactores engagement.

See how we work

What Do Common Context Ontology Terms Mean?

Ontology: A formal model of the things in a domain, how they relate and the rules that apply to them, written so both people and machines can use it.
Context ontology: An ontology of your business that AI reads at answer time, so agents follow your definitions and rules.
Enterprise context layer: The shared layer of definitions, relationships, rules and access policies that every AI agent and analytics tool in a company reads from.
Ontology layer: The part of a data and AI stack where the ontology sits, between the source data and the agents and tools that query it.
Knowledge graph: Connected data stored as entities and relationships, organized by an ontology so it can be traversed and queried.
Virtual knowledge graph: A knowledge graph that queries source databases in place, translating graph queries into SQL instead of copying the data.
Semantic layer: A governed set of metric and dimension definitions that BI tools and agents use to calculate numbers the same way.
Governed metric: A KPI with one approved definition and a named owner, reconciled to the report of record.
OWL, SHACL and R2RML: W3C standards for defining ontology classes (OWL), checking data against rules (SHACL) and mapping relational data to a graph (R2RML).
SPARQL: The W3C query language for graph data.
Model Context Protocol (MCP): An open standard through which AI agents call tools and data sources.
Data steward: The person accountable for a definition or data set, who approves changes before they are published.
Golden questions: A fixed set of business questions with known correct answers, run against every ontology change to measure accuracy.
FDE: The Mactores lead embedded with your business and data teams for the whole engagement, who runs the modeling sessions, owns the architecture calls and answers for the production date.

How Can Mactores Help You Out?

Mactores gives your AI the business context it is missing, on a contracted date. Start with an answer review if your agents already give wrong answers, a first-release ontology if you know the questions, or a platform assessment if you are choosing where context should live. Each path ends with a fixed fee and a production date in writing.

You bring the domain knowledge, the systems and the priorities. We bring the architecture, the delivery discipline, AWS depth and the experience of putting agents into production on regulated data since we started building on AWS in 2008, where a wrong answer becomes an audit finding rather than a support ticket. It’s why every model we build pairs each definition with an owner, each rule with a test, and settles access before the first query runs.

If this sounds like you

Where we start

What you walk away with

Agents are live, but their answers can’t be trusted

Where we start: Agent answer review

What you walk away with: The missing definitions and rules, ranked, with a first-release scope and date

The questions are clear, and the answers must be right

Where we start: First-release context ontology

What you walk away with: An ontology in production, with stewards trained and golden questions passing

You are choosing where business context should live

Where we start: Platform assessment

What you walk away with: A recommendation for your stack across the Context Ontology Accelerator, AWS Context and other context layers

Context is one layer of a working AI system. When the agents themselves are the gap, AI agents for applications is where the work continues, with the same phase gates and the same commercial terms.

If your agents are moving from pilot to production, the question is no longer whether you need more data. It’s whether your AI understands the right context, respects the right boundaries and can prove what it did. A focused context ontology assessment is the practical first step: we find your highest-value decision domain, map the systems and data involved, surface the conflicting definitions and policy gaps, and set out a phased plan with clear acceptance criteria.

When the data underneath isn’t ready, data platform modernization comes first, so the ontology has clean, governed sources to map. Your team keeps the ontology, the rules and the know-how. Your agents stop guessing what your business means.

Bring one question and one owner

In one session you get our diagnosis, a draft scope and the date we’d commit to.

A working session with Mactores FDEs.

Book a scoping call

What Do Teams Want to Know Before Building a Context Ontology?

What is a context ontology?

A context ontology is a structured, governed model of the entities, relationships, definitions, policies and constraints that give your data business meaning, made available to AI at the moment it answers. It tells applications and agents not only what data exists, but what it means and how it may be used, so answers follow your definitions instead of guesses.

What separates a context ontology from a data catalog?

A data catalog describes the data assets you have and where they live. A context ontology defines the meaning, relationships, rules and decision context behind those assets. The two work best together: the catalog helps people find data, and the ontology helps people and agents use it the same way every time.

Do we need a knowledge graph to use a context ontology?

Not always. A knowledge graph is a strong pattern when relationships, impact analysis and multi-hop questions matter. Other implementations use a semantic layer, governed data products, a metadata platform, vector search or a mix of these. We choose the lightest design that answers your first questions reliably.

What is the difference between an ontology, a knowledge graph and a semantic layer?

An ontology defines meaning: the types of things in your business, how they relate and the rules that apply. A knowledge graph holds the connected data organized by that model. A semantic layer serves governed metrics, such as revenue or churn, to BI tools and agents. Agents answer most reliably when all three agree, and the ontology is what keeps them consistent.

Is AWS Context available yet?

Not yet. AWS announced AWS Context on 17 June 2026 at AWS Summit New York and, as of early November 2026, lists it as coming soon, with no preview or general availability date. Its open-source companion, the Context Ontology Accelerator, reached general availability on 31 July 2026, and AWS says ontologies built with it can be used and managed in AWS Context.

Should we wait for AWS Context before building an ontology?

There is little reason to wait. Most of the effort in a context ontology goes into agreeing definitions with your experts, mapping sources and writing rules, and that work is the same whichever platform runs it. AWS says accelerator ontologies carry into AWS Context, so a first release built now keeps its value when the managed service arrives.

Does the Context Ontology Accelerator cost anything, and does AWS support it?

The code is free and open source under the Apache 2.0 license, but you run it yourself. AWS says you can deploy it on your own or engage AWS Professional Services, and its GitHub repository is a read-only mirror that accepts issues but not pull requests. You still pay for the AWS services underneath it: Neptune for the graph, OpenSearch Serverless for search and Bedrock for the models.

Doesn't MCP already give AI agents context?

MCP gives agents a common way to reach tools and fetch data, but it doesn't tell them what the data means. An MCP connector can return an order, a balance or a policy document. It can't say which definition of an active customer your finance team uses, or which rule applies next. A context ontology is often served to agents over MCP, so the two work together.

Can a context ontology work with our existing data warehouse or lakehouse?

Yes. The ontology is designed around your current investment rather than replacing it. It can span a warehouse, a lakehouse, operational databases, SaaS applications, documents and APIs, and a virtual knowledge graph can query many of those sources in place instead of copying the data.

How long does a context ontology engagement take?

A first release built around 10 to 20 business questions on a small set of sources usually takes 8 to 12 weeks from discovery to production. Larger programs ship as further dated releases, so value arrives early rather than after every domain is modeled. The exact production date is set in discovery and written into the SOW.

Is a context ontology suitable for regulated industries?

Yes, and it is often most valuable there, because it makes policies, lineage, access controls, approvals and audit trails explicit. Regulated data adds policy design and testing to the scope, but the controls are built into the model rather than added afterward, which keeps delivery on its date.

Which teams should be involved?

Business domain owners, data governance leads, data platform owners, enterprise architects, security and privacy teams, AI or analytics teams and application owners. The programs that work best give business stewards a clear role in defining meaning and approving changes, because they are the ones who know what a term should mean.

After go-live, who owns the ontology and what happens next?

You do. The ontology, mappings, rules, test questions and documentation live in your own account and repositories, and ownership and exit terms are written into the SOW before any build begins. An ontology is a living asset, so stewardship, monitoring, change control and quality checks are in place at handover, and your stewards are trained to keep it current.

Still have a question?

Send it over with the agent, the question and the systems behind it.

Email lets-talk@mactores.com

Email us

Which Question Does Your AI Keep Getting Wrong?

Bring it to us. We'll trace it to the definitions and rules it is missing, and put a date on fixing it.

01
Bring one question and three answers your agent gave, and walk through them with an FDE in a single working session.
02
Within a week, receive a diagnosis, a draft first-release scope and a target production date.
03
Countersign a fixed-fee SOW and start with discovery.

You're protected by a 30-day satisfaction guarantee, and production defects reported within 90 days of acceptance are fixed at our cost.

Fix my AI's answers Email lets-talk@mactores.com