Graph engineering: designing how AI systems know and work

The short answer

Graph engineering is the practice of deliberately designing the nodes, relationships and rules through which an AI system knows something or completes work. The term is emerging rather than formally standardised. In current AI engineering discussions, it usefully covers two different structures: a knowledge graph, which represents entities, facts and their relationships, and a task graph, which represents steps, dependencies, routing, state and control in an agent workflow.

The practical value is not the diagram. It is the decision to make structure executable and testable. A knowledge graph can help an AI system connect information that sits across documents and databases. A task graph can show where an agent may branch, call a tool, retry, request approval or stop. Some systems need one of these graphs; a smaller number need both. The right starting point is a recurring business question or workflow that flat retrieval or a single agent loop cannot handle reliably.

Why graph engineering is appearing now

Early generative AI applications were often built around one prompt and one response. Retrieval-augmented generation (RAG) added relevant source passages, while tool use allowed a model to take actions. Production systems now combine retrieval, tools, memory, validation and human decisions across multiple steps. That creates relationships which matter but are difficult to govern when they remain implicit in prompts and application code.

Graph-based systems are not new. Knowledge graph engineering has long dealt with ontologies, entity identity, relationships, provenance and query models. What has changed is the pressure created by AI applications that need to traverse information across sources and coordinate work over time. Microsoft's GraphRAG project combines text extraction, network analysis, prompting and summarisation. LangGraph's Graph API represents an agent workflow through shared state, nodes and edges.

“Graph engineering” is therefore best treated as a useful umbrella, not a settled job title or a single technology stack. It names a shift from tuning isolated model calls towards engineering the topology around them.

The two graphs solve different problems

A knowledge graph and a task graph may both contain nodes and edges, but their semantics are different. Confusing them usually leads to an architecture that is difficult to explain or test.

| Graph | Nodes represent | Edges represent | Primary question | | --- | --- | --- | --- | | Knowledge graph | Customers, products, policies, events, claims or other entities | Meaningful relationships such as owns, supplies, depends on or supersedes | What is connected, and how do we know? | | Task graph | Actions, agents, tools, checks, approvals or states | Sequence, dependency, branching, retry or escalation | What should happen next, under which conditions? |

Consider a service business answering a question about a delayed customer project. Its knowledge graph might connect the customer, contract, project, milestones, suppliers, open risks and responsible staff. Its task graph might retrieve those records, check access, identify missing evidence, draft a status explanation, send it to a reviewer and stop until approval. The first graph supplies structured context; the second governs execution.

This distinction also clarifies where adjacent practices fit. Context engineering determines what information reaches a model at a particular moment. Loop engineering makes an agent's repeated observe–act–verify cycle reliable. Graph engineering deals with relationships and topology across information or work. A production system can use all three without treating them as competing labels.

Knowledge graphs make relationships queryable

A knowledge graph represents domain concepts as entities and typed relationships. A business may already hold the underlying facts in a CRM, document store, data warehouse and ticketing platform. The graph does not make those facts true; it creates a consistent relationship layer through which systems and people can traverse them.

A useful knowledge graph normally requires more than extracting names from text. It needs:

1. A bounded domain and competency questions. Define the questions the graph must answer, such as “Which active projects depend on a supplier affected by this outage?”
2. A schema or ontology. Define the entity types, relationship meanings and constraints that matter in the domain.
3. Entity resolution. Decide when records from different systems refer to the same customer, product, person or event.
4. Provenance and time. Retain where a claim came from, when it was valid and whether it has been superseded.
5. Quality rules. Detect impossible relationships, missing identifiers, conflicting claims and stale data.
6. A serving model. Expose the graph through queries, APIs or retrieval patterns that applications can use safely.

This work remains important when an LLM assists with extraction. A model can propose entities and relations, but confidence is not provenance, and fluent output is not a data-quality control. Research on LLM-assisted knowledge graph engineering describes useful assistance across graph-development tasks, while the related LLM-KG-Bench work found that zero-shot use was not sufficient for reliable knowledge graph generation. The engineering task is to combine automation with schemas, validation and accountable review.

Task graphs turn agent behaviour into an inspectable workflow

A task graph makes the execution structure of an AI system explicit. Each node performs a bounded operation: classify a request, retrieve evidence, call a service, generate a draft, test an output or request approval. Each edge encodes a transition and its condition.

This structure can support sequences, branches, parallel work, loops and recovery paths. It also gives a team stable places to attach permissions, timeouts, budgets, tracing and tests. Those qualities matter more than a visually impressive graph.

The graph should not automatically contain many agents. Google Research's 2026 evaluation of 180 agent configurations found that architecture needs to match the task: centralised multi-agent coordination helped parallelisable work in its experiments, while multi-agent variants degraded performance on sequential planning tasks. Anthropic similarly reports in its multi-agent research system that parallel research can benefit from an orchestrator–worker pattern, but at substantially higher token cost and with additional coordination challenges.

Start with one agent and one controlled loop. Split work into more nodes or agents only when there is a real dependency, distinct permission boundary, parallel task or independent verification role. The agent harness—the surrounding runtime, tools, memory, policies and observability—then enforces the graph rather than relying on the model to remember it.

GraphRAG connects retrieval with relationship structure

Conventional vector retrieval is effective when the answer is located in passages semantically similar to the question. It becomes less direct when answering requires multiple hops: a project refers to a supplier ID, the supplier record refers to a parent company, and a separate risk register records an incident affecting that parent.

GraphRAG is a family of approaches that uses graph structure as part of retrieval and synthesis. Microsoft's open-source pipeline can extract entities, relationships and claims, identify communities, generate multi-level reports and embed content. Its query engine supports local searches around particular entities and global searches over broader community summaries. AWS also provides a managed GraphRAG capability with Amazon Neptune Analytics, combining vector search with graph data.

The trade-off is material. Building the index can require model calls, entity resolution, storage and ongoing refresh. Microsoft's repository explicitly warns that GraphRAG indexing can be expensive and recommends starting small. The graph can also amplify extraction mistakes if relationships are accepted without evidence.

Use GraphRAG when important questions genuinely depend on connected evidence or dataset-wide themes. For direct questions answered by a small number of well-indexed passages, simpler retrieval may be faster, cheaper and easier to operate. A graph is not an automatic upgrade from the alternatives to embedding-only retrieval; it is another retrieval structure to evaluate against representative questions.

A practical graph engineering framework

The following six-stage framework keeps the work tied to an outcome rather than a technology demonstration.

1. Begin with a decision and a baseline

Choose a recurring question or workflow with a known owner and measurable failure. Record the current answer quality, completion time, review effort, incident rate and operating cost. Without a baseline, a graph can appear sophisticated while adding no practical value.

2. Choose the minimum graph

Ask whether the difficulty lies in connected information, execution dependencies or both. Build a knowledge graph for relationship-heavy questions. Build a task graph for branching, long-running or controlled workflows. Do not build two graphs because the terminology permits it.

3. Define semantics before scale

For a knowledge graph, define entity identity, relationship meaning, direction, cardinality, time and provenance. For a task graph, define node inputs and outputs, transition conditions, state ownership, retry rules and stop conditions. A small graph with precise semantics is more useful than a large ambiguous one.

4. Put evidence and authority on the edges

Record which source supports a knowledge relationship and which rule permits a workflow transition. Add human approval before high-impact actions. Make permissions explicit at the tool and data layers, rather than expressing them only in a prompt.

5. Evaluate paths, not just final prose

Test entity resolution, multi-hop retrieval, route selection, tool arguments, denied actions, retries and recovery. Retain traces that show which nodes executed, what evidence was retrieved and why a transition occurred. Compare the complete system with the baseline, including latency and cost.

6. Operate the graph as a changing product

Schemas evolve, sources become stale, tools change and workflows acquire exceptions. Assign owners, version important definitions, monitor graph quality and review high-risk transitions. A graph that cannot be maintained will gradually become an authoritative-looking source of wrong answers.

A worked example for an Australian service business

Imagine an Australian managed-services provider wants an assistant that explains which client commitments may be affected by an incident. Relevant evidence is distributed across contracts, service records, tickets, infrastructure inventories and supplier notices.

The first release can remain deliberately narrow:

| Layer | First-release design | | --- | --- | | Outcome | Help an authorised service manager prepare an evidence-linked impact brief. | | Knowledge nodes | Client, contract, service, asset, supplier, incident and obligation. | | Knowledge edges | Client holds contract; contract covers service; service depends on asset; asset depends on supplier; incident affects supplier. | | Task nodes | Authorise user; identify incident; traverse affected services; retrieve source records; flag conflicts; draft brief; human review. | | Stop rule | Do not generate a client-facing brief when identity, contract coverage or source evidence is unresolved. | | Success measures | Correct affected-service recall, evidence precision, review time, false alerts, latency and cost per brief. |

This design does not permit the AI to change a contract, declare an outage or contact a client. It supports a person responsible for those decisions. If the pilot shows that simple joins and search answer the questions reliably, the business may not need a dedicated graph platform. That is a successful finding, not a failed graph project.

Governance, privacy and security belong in the graph

Knowledge graphs can concentrate sensitive relationships. Even when an individual data point appears harmless, combining employment, customer, location or behavioural records may reveal personal information. Task graphs can create a different risk: a valid node may be reached by an invalid path, or an agent may gain a tool it should not use for that request.

For organisations covered by the Privacy Act 1988, the OAIC states that privacy obligations apply to personal information input into an AI system and to generated output that contains personal information. Its guidance for commercially available AI products recommends due diligence, proportionate oversight and careful attention to accuracy, security and overseas disclosure.

Translate those responsibilities into design controls:

• minimise which personal information becomes a node or attribute;
• enforce access at query, node and tool boundaries;
• preserve source, purpose, consent and retention metadata where relevant;
• prevent models from converting uncertain matches into asserted identities;
• log consequential traversals and actions without leaking sensitive content;
• provide correction, challenge and human-intervention paths;
• test for indirect disclosure produced by combining relationships.

Australia's current AI safety guardrails also emphasise data quality and provenance, testing, human control and record keeping. Graph engineering can help implement those practices because it creates explicit locations for evidence, controls and audit records. It does not itself establish compliance.

Common failure modes and trade-offs

Treating every noun as an entity

Unbounded extraction produces a dense, noisy graph. Model only concepts needed to answer the competency questions, and establish identity rules before ingesting at scale.

Confusing an edge with evidence

An extracted relationship is a claim until supported by a source and validation policy. Store provenance, confidence, valid time and review status separately from the relationship label.

Adding agents where functions would work

Many nodes should be deterministic code, queries or policy checks. An LLM is useful where interpretation is required; it should not replace a reliable function merely to make the graph “agentic”.

Hiding control flow inside prompts

If a critical approval or stop rule exists only as natural-language guidance, it is difficult to guarantee and test. Enforce it in the orchestration and permission layer.

Ignoring graph economics

Graph extraction, storage, evaluation, observability and maintenance add cost. Multi-agent task graphs add model and coordination cost. Measure total cost per successful outcome, not only model accuracy.

Building a graph without an owner

Relationships and workflows decay. Give domain owners responsibility for semantics and exceptions, and give engineering owners responsibility for runtime behaviour, security and reliability.

How to decide whether graph engineering is worth it

Graph engineering is a strong candidate when at least one of these conditions is present:

• users repeatedly need to connect evidence across several systems or documents;
• the same entity appears under inconsistent identifiers;
• questions require multi-hop reasoning or dataset-wide themes;
• an AI workflow branches, runs for a long time or uses consequential tools;
• different steps require distinct permissions or independent verification;
• teams cannot currently explain why an answer or action followed a particular path.

It is probably premature when a relational query answers the question directly, a standard search index retrieves sufficient evidence, the workflow is short and deterministic, source quality is poor, or no team owns the domain model. In those cases, improve the data contract, retrieval or AI-agent delivery foundations first.

For a pilot, select 20–50 representative cases and a bounded slice of the domain. Compare the graph approach with the simplest credible alternative. Proceed only if it produces a worthwhile improvement in evidence quality, controllability, review effort or another outcome that matters to the business.

Frequently asked questions

Research and further reading

• Microsoft Research: Project GraphRAG
• Microsoft GraphRAG: indexing overview
• Amazon Bedrock: build a knowledge base with Neptune Analytics graphs
• LangGraph: Graph API overview
• Google Research: towards a science of scaling agent systems
• Anthropic: how we built our multi-agent research system
• OAIC: privacy and commercially available AI products
• Australian Government: voluntary AI safety guardrails

The takeaway

Graph engineering is valuable when relationships or execution paths have become too important to remain implicit. A knowledge graph can make connected evidence queryable. A task graph can make agent behaviour inspectable and controlled. Together, they can support AI systems that are easier to trace, test and govern—but only when the graph is bounded by a real decision, trusted evidence and an accountable owner.

Start with one question or workflow. Establish the simplest baseline. Model the minimum graph, attach evidence and authority to its paths, and test the whole system on representative cases before scaling it.