Context Engineering

rygg is the foundation for context engineering

Context engineering means giving people and agents exactly the context a task needs, verified and with its source. rygg provides it: a managed ontology, a maintained context graph, defined context packages for agents, and people who approve what the agents suggest. Built on human-centeredness, measured with evals.

1 · ryggContext graph
2 · Context package6 verified nodes · release 2026.10
3 · AgentTest case writer
4 · SuggestionTC-31 with 6 sources
5 · ReviewTest lead approves
6 · VerifiedBack in the graph

1rygg holds verified context: users, requirements, decisions, evidence.
2Context package For a task, rygg selects only the nodes it needs, with status and source.
3Agent The agent works with this package instead of guessing.
4Suggestion The result comes back as a suggestion with the sources it used.
5Review A person with the right to decide approves, changes or rejects it.
6Verified Only then is it part of the graph. The next task starts with more context.

Stages

Where your engineering stands, and what context each stage needs

With every stage, agents take over more of the work, and context decides more of the result. Choose a stage.

Stage 2Delegated

What happens

An agent carries out a task across files and runs tests. A person reviews the result. Gaps in context turn into plausible assumptions.

rygg provides

Context packages per task, suggestions only, review by the responsible role.

personagentsuggestionverified, back in the graph

From stage 2 on, context decides the quality of the result. rygg covers the context and the coordination between people and agents. System structure and architecture stay with your engineering.

Feedback loops

Improve the environment, not only the output

Two loops make agents better over time. In the first, the agent receives context before it acts and is checked afterwards. In the second, the team learns from what went wrong and improves context and checks. rygg supplies both: the context that steers and the checks against the graph.

Context package

What an agent receives

Slice

Node types and relations relevant to the task, not the whole graph.

Status

Verified nodes, and assumptions only when marked as such.

Provenance

Source, date and scope of every node.

Rights

What the agent may read and where it may place suggestions.

Size limit

So the relevant context is not lost in a long prompt.

Version

Release of the graph, so every answer can be reproduced.

Engineering with the graph

What agents in your engineering do with it

AI agents write requirements, test cases, code and documentation in minutes. rygg gives them the knowledge about users and contexts of use that they cannot get from code or tickets, and every suggestion shows where it comes from.

Test cases from requirements

Test cases that cover the user requirement and the context of use behind it, not only the function.

Agent context

Agent task: Writes test cases with acceptance criteria
Reads: Requirement, context of use, known use errors
Suggests: Test cases linked to requirement and context
Approved by: Test lead

Metric: Test cases approved without changes

Pull requests with user context

Each change shows which user requirements and contexts of use it affects.

Agent context

Agent task: Annotates pull requests with affected requirements and contexts
Reads: Code-to-requirement links, requirements, contexts of use
Suggests: Annotation with node references
Approved by: Engineering lead

Metric: Changes with traceable user impact

Documentation in users’ words

Technical documentation that uses the terms users use for their tasks.

Agent context

Agent task: Writes documentation and checks it against defined terms
Reads: Terms from the ontology, tasks, user groups
Suggests: Text drafts, term deviations
Approved by: Technical writer

Metric: Term deviations per release

Service answers with known use errors

Support answers that know which use errors occur with a function and under which conditions.

Agent context

Agent task: Proposes answers for support cases
Reads: Use errors, contexts of use, verified fixes
Suggests: Answer draft; unknown cases as research questions
Approved by: Service lead

Metric: Cases solved with a verified source

Agent tasks

What agents do in each use case

Each use case defines what the agent reads, what it may suggest and who approves.

Use case	Agent task	Reads	Suggests	Approved by
Shared basic answersHuman-centered Enterprise	Onboarding assistant answers basic questions	Verified core statements, value propositions, user groups	Open questions it could not answer	Strategy owner
Assumption registerHuman-centered Enterprise	Finds statements in strategy papers that have no source in the graph	Documents, existing statements and their status	Assumption nodes with the text passage	Owner of the topic
Contradictions between departmentsHuman-centered Enterprise	Compares statements about the same user group across departments	Statements per department with origin	Contradiction with both sources	Domain owners of both sides
Board viewHuman-centered Enterprise	Prepares the delta since the last meeting	Decisions, evidence changes, open assumptions in the period	Summary draft with node references	Board office or management
Roadmap evidence checkHuman-centered Product Development	Maps roadmap items to requirements and marks items without evidence	Roadmap items, requirements, findings with status	Links and gap markers	Product manager
Coverage of contexts of useHuman-centered Product Development	Computes coverage and proposes research questions for gaps	Contexts of use, products, variants, markets	Research questions with priority	UX research lead
Reuse of researchHuman-centered Product Development	Answers “what do we know about task X” with sources	Findings and studies with scope and date	Answer with node references, or “no finding”	Research lead for new findings
Evidence of conformityHuman-centered Product Development	Assembles the evidence dossier per release	Chain from context of use to evaluation for the release	Dossier draft with gaps marked	Quality and approval
Context packages per agentAgent governance	Every agent receives a defined package instead of the whole graph	Package definition: node types, status filter, size limit	Request log with package version	Platform owner
Review queue and decision rightsAgent governance	Places suggestions in the queue of the responsible role	Decision rights per role and node type	Suggestion with sources	Role with the right to decide
Evals in operationAgent governance	Eval agent runs test questions with expected answers against the graph	Test questions, expected answers, graph release	Eval report per release	Platform team
View for works council and data protectionAgent governance	Lists affected roles and tasks for a new agent	Roles, tasks, agreements, agent permissions	Impact overview draft	Works council and HR
Impact of a changed requirementProduct compliance and customer requirements	Runs the reverse search and lists affected objects with path	Requirements with status, bill-of-material links, customers	Impact list with paths	Product compliance
Customer questionnairesProduct compliance and customer requirements	Drafts answers from canonical requirements	Canonical requirements, evidence with validity, earlier answers	Answer drafts with source and validity	Key account and compliance
Validity of evidenceProduct compliance and customer requirements	Flags expiring evidence and drafts requests to suppliers	Evidence with scope and expiry date	Expiry list, request drafts	Purchasing and compliance
Substitution decisionsProduct compliance and customer requirements	Assembles options with test results and open questions	Options, test results, affected requirements	Decision template with sources	Engineering board
Gate evidence checkPortfolio and value	Checks gate documents against the required evidence types	Gate criteria, initiative, evidence with status	Gap list per gate	Gate owner
Expired assumptions and stalled initiativesPortfolio and value	Lists initiatives without new evidence and expired assumptions	Initiatives, assumptions with dates, evidence timeline	Weekly list with reasons	PMO
Value case and 90-day reviewPortfolio and value	Compares forecast and measurement and drafts the review	Value case, metrics, value drivers	Review draft with deviations	CFO or controlling
Decision journalPortfolio and value	Extracts decisions from minutes as drafts	Minutes, existing decisions, assumptions	Decision drafts with text passages	Decision owner
Signal triageSupply chain and risk	Maps signals to supply relationships and affected objects	Signals, supply relationships with tier, parts, programs	Risk with impact path	Purchasing
Change of regulatory statusSupply chain and risk	Marks obligations and evidence affected by a status change	Obligations, legal basis with status, evidence	Change list	Compliance
Accepting residual riskSupply chain and risk	Prepares the decision pack with measures and residual risk	Risk, causes, effects, measures, indicators	Decision pack with sources	Management
Risk gapsSupply chain and risk	Produces the gap list	Risks, owners, indicators, measures	Gap list	Risk manager
Repeat root causesQuality and product safety	Searches similar complaints and root causes	8D reports, root causes, measures, effectiveness	Similar cases with references	Quality engineer
From 8D to FMEAQuality and product safety	Proposes FMEA updates from closed 8D cases	8D, FMEA, characteristics	FMEA update draft	FMEA moderator
Use errors from the fieldQuality and product safety	Maps field observations to failure modes	Field findings, contexts of use, failure modes	Link suggestions	Product safety
What was known whenQuality and product safety	Reconstructs the state of the graph at a given date	Nodes with creation and change dates	Snapshot report with node references	Product safety and legal

Rules

What applies to every agent

Agents read the graph instead of guessing.
Agents write suggestions only, never verified nodes.
Every statement in an answer refers to a node.
No evidence, no answer: “no finding” is allowed.
Expired and contradicted nodes are treated as such.
Access follows the role, for agents as for people.

Integration

Through an API, for example as an MCP server, so that agents in the tools you already use can query the graph.