Agent “first” application design requires builders and teams to think beyond screens, buttons, widgets, and even prompts and context. The unit of system design becomes agent behavior: delegation, boundaries, entitlements, security, context, memory, and recovery.
For enterprise knowledge work, that shift means building apps around user, system, and agent behavior, with traceability, compliance, and evidence as first-class UX/DX requirements.
Agent-first applications allow for multimodal interactivity, delegation by the user to use tools and integrations, act on the response from those tools using context, memory, agent to agent communications, and further multimodal interactions. This white paper considers these to be “agentic” knowledge work applications, referred to as agentic apps in the rest of this whitepaper.
For these agentic apps, conversation + context bots or chat + RAG experiences can demo well while falling short of production requirements. The challenge extends beyond model capability. The gap is trust: shipping systems where outputs are in-scope, evidence-backed, controllable, and repeatable.
This paper proposes a platform thesis: building agentic apps requires a fundamental rethink of both the user experience and the developer experience around behavior, delegation and review. Domain experts define the intended work and acceptance conditions. The authoring environment derives annotations that map this intent to domain meaning, supported capabilities and user interactions. A graph records the work and its dependencies. These connections guide execution and review: users can inspect results against accepted intent, and builders can trace corrections into application changes. Reliable agent-first systems require first-class primitives for (1) probabilistic behavior, (2) constraints that stay attached end-to-end (knowledge scope, permissions, approvals), and (3) operational evidence (lineage, artifacts, and regression over time).
An Integrated Knowledge Environment (IKE) unifies capture, governed knowledge, and operations so builders can create, deploy, operate and improve agentic apps, and users can delegate and review work within stable boundaries, with replayable, reviewable execution.
The application combines a defined role, domain concepts, working methods, governed sources, capabilities and acceptance criteria into a system that can carry out delegated work within clear operating boundaries. Software handles known procedures and mechanically checkable rules; models contribute interpretation and bounded judgment. Versioned definitions and structured work records let the application be reviewed, reused and improved as knowledge and methods change.
Figure 1: UX and DX around an agentic app
Scope (what this paper is and is not)
This technical whitepaper develops the architectural thesis, design requirements and proposed mechanisms of an Integrated Knowledge Environment (IKE) for agentic apps. It is written for architects, builders and domain experts evaluating how intent, knowledge, authority and evidence shape application behavior. Knowledge work involves using ability, critical thinking, and complex problem-solving to analyze information and create new knowledge, strategies, or solutions. The end users and use cases include knowledge worker/builder, enterprise and B2B workflows where outputs must become governed, reviewable work products.
This paper is not about:
“Vibe coding” agents and developer-only IDE copilots
Consumer concierge agents
Pure chat/RAG “context bots” without tool delegation, bounded autonomy, and evidence-backed artifacts
Technical evaluation should examine whether the model is coherent, how its components divide responsibility and which tests establish its limits. Product availability, customer results, pricing and commercial packaging need a separately dated account. Implementation and economic benefits must be tested in specific applications.
The architecture defines responsibilities and contracts. Specific deployments may implement them through different services, stores and runtimes. These requirements provide a basis for design and evaluation. Descriptions of IKE and Builder define architectural responsibilities and required behavior. The supplier assessment is illustrative. Implementation status and demonstrated behavior must be established for a specific version and deployment; measured benefits require evidence from actual work.
Keywords
Agentic refers to the ability to act independently and make decisions toward achieving a goal. In the context of artificial intelligence, it describes systems that can perform tasks autonomously with minimal human intervention (delegation). IBM, 1
For the purposes of this white paper, agentic, agent-first, and delegation-first have the same essential meaning above, and these terms may be used interchangeably.
Many enterprise applications are organized around records and defined transactions: creating a case, retrieving information, recording an approval or updating status. They also support knowledge work through search, analysis and workflow. Reliable operation depends on data integrity, access control, valid state transitions and correct completion of authorized actions.
An agentic app takes responsibility for parts of the interpretation and investigation that a person would otherwise coordinate across those systems. It connects an intended outcome to relevant evidence, domain meaning and available capabilities, then carries the work through uncertainty and correction. Acceptance requires correct execution, an interpretation supported by evidence and a result that serves the intended purpose.
This expands the trust requirements and the design surface. Users need ways to express intent, inspect findings, resolve ambiguity and change direction. Builders need representations that connect those interactions to domain knowledge, capabilities and acceptance conditions. Existing transactional services remain important execution and recordkeeping components. New agentic apps can build on them to support work that previously depended on a person assembling and interpreting the information.
Across enterprise software, “agentic AI” is moving from experimentation toward core workflows, and users increasingly expect reliability, controls, and repeatability. In practice, this is a design cliff: teams struggle to make agent outputs trustworthy, not merely plausible. That expectation changes what it means to build an AI product. It is no longer enough for an agent to produce a plausible answer. The agent must produce work product and/or outcome that is bounded, reviewable, and explainable, and it must do so consistently across the knowledge, memory, tooling (including via MCP), and the context provided to it through multimodal channels. Microsoft and LinkedIn, 2024, 2
AI adoption supplies the context for this problem. Microsoft and LinkedIn’s 2024 Work Trend Index reported that 75% of surveyed knowledge workers used AI at work. The engineering question is what lets an application turn model capability into work people can accept and use. Microsoft and LinkedIn, 2024, 2
1.1. What we mean by an agentic app
In this paper, an agentic app is a system where a user can interact with and delegate an outcome, and the system can do autonomously:
Plan and take actions using tools and integrations (not just respond in chat)
Act on tool outputs using managed context and memory (not only retrieval at query-time)
Work multi-modally across artifacts that knowledge workers typically handle (docs, tables, tickets, PDFs, web pages)
Return evidence-backed artifacts (not just prose) that are the expected work product for the goal or tasks.
Effectively interact with other agents via standard protocols like A2A.
Recover safely when blocked or uncertain (ask, stop, escalate, require approval)
When these characteristics are missing, products marketed as agentic, but on closer examination tend to show as conversation + context bots, engineered assistants, RAG experiences that may demo well but fail under operational requirements.
Coding agents are an established form of agentic knowledge work. We treat them separately because their UX and DX are anchored in an unusually strong feedback loop: compilers, tests, and CI provide objective checks, and IDE workflows provide a natural surface for review (diffs, traces, breakpoints). The workplace knowledge work agents in this paper face different constraints: authority and recency are source-dependent, permissions and boundaries are non-negotiable, and operational evidence must travel end-to-end so work products are reviewable, auditable, and stable over time.
The problem is that agentic software has a design, deployment, and production chasm:
easy: conversation bots.
hard: shipping, governing, and operating agent behavior in production, with integrations and RAG.
hardest: agent first (delegation-first) UX and DX, where users assign outcomes with boundaries and then review evidence, securely without bypassing entitlements.
The gap spans tooling, design and development. Because reference patterns for agentic knowledge work are domain-specific, teams may lack proven patterns for designing the workflows, controls, and operational surfaces that make agentic systems trustworthy. As a result, teams either (a) avoid high-stakes deployments, or (b) ship systems that are easy to build but hard to trust.
Agentic coding applications face the same design gap. A model may generate an agent design and its code while still struggling to design the novel UX and DX of an agentic app: how people delegate, inspect and correct domain work, and how builders express and evolve that behavior. Where established patterns are sparse, models need domain meaning, working methods and acceptance criteria that coding-agent examples alone cannot supply. The proposed IKE model makes these design conventions explicit through human-owned intent, derived annotations and graph representations. Builders and models can then use them to develop and test those experiences.
ReAct demonstrates how interleaving model reasoning with actions and observations lets an agent adapt as it works on the tasks studied. Production use adds questions about who authorized those actions, which evidence they relied on and whether the completed task satisfies the user’s intent. Yao et al., 2023, 3
1.2. Why it is hard to do agentic app UX/DX well
Even when an agent can complete tasks convincingly in a demo, production deployments break for three structural reasons: probabilistic behavior, end-to-end constraints that must travel with the work, and operational evidence requirements.
1.2.1. Probabilistic behavior
Agentic systems do not behave like deterministic software. They generate actions and outputs that vary across runs, contexts, and tool responses. That changes the design target:
You are not designing for “the correct answer.” - You are designing for acceptable behavior under uncertainty, including bounded actions, safe defaults, and explicit recovery paths.
Reliability becomes a product surface.
A trustworthy agent must expose what it is doing, where it is uncertain, and what it will do next when inputs are incomplete. Models may continue with plausible answers when their knowledge or the available evidence is insufficient. The application needs ways to request evidence, clarify intent and correct unsupported interpretations. Evaluation must test when the model answers and when it abstains. Zhang et al., 2024, 4
Risk management must be built-in, not added later. - Frameworks like the NIST AI Risk Management Framework (AI RMF 1.0) formalize trustworthiness concerns (validity, reliability, safety, accountability, transparency) as design and operational requirements, not just model evaluation artifacts. NIST, 2023, 5
Implication: Primitives are required for units of context, actions, bounded autonomy, uncertainty handling, and controlled failure modes. There is no certainty that prompt/context iteration or engineering will produce stable behavior and can certainly be impacted by the LLM model in play.
An application can also detect conditions the model should never have to infer: a missing required field, an expired authorization, an inaccessible source or an invalid calculation. These checks establish a reliable boundary around parts of a variable process.
1.2.2. Constraints must travel
End-to-end workflow contracts and packaged primitives must travel with the work that the agent does.
Traditional software often separates “build-time intent” from “run-time operation.” Agentic workflows cannot.
Once you deploy the agent, the interactions and behavior must continue to work within the policies and controls created, and for the user delegation experience be that the agent behavior is trusted - they must persist end-to-end:
First-mile: what the system is allowed to know (knowledge scope, provenance, permissions), and how knowledge is captured and structured.
End-to-end and last-mile: what the system is allowed to do (tools, integrations, approvals, tool constraints), and how the outputs become work products that is presented and reviewed as part of the UX.
Across both: policies, boundaries, approvals, and artifacts must remain attached and enforced at each behavioral/generative step.
This is increasingly non-negotiable in regulated and enterprise contexts (e.g. like entrenched polices and procedures). For example, the EU AI Act introduces record-keeping and human oversight expectations for certain categories of systems, reinforcing traceability and operational controls as practical requirements. European Commission, 6AI Act, Article 12, 7AI Act, Article 14, 8
Implication: Agentic apps need platform-level support for policy enforcement, knowledge boundaries, review gates, and artifact handling that persists from capture to execution to delivery.
This requires preserving identifiers and policy references across transitions. A source’s access restriction has consequences for derived material. A handoff to another agent must carry the relevant task scope. An approval must apply to the particular action and target being executed.
1.2.3. Ops need evidence
In production, “the agent seemed right” is not an acceptable operational posture. Operators need evidence to answer: What happened? Why did it happen? Would it happen again?
Reliable operations require three kinds of evidence:
Lineage: what sources, tools, and steps led to the outcome (the “why”).
Artifacts: the tangible outputs and intermediate work products (the “what”).
Regression over time: probabilistic assurance that changes in models, prompts, tools, or knowledge do not introduce unobserved behavioral drift. Variable behavior needs repeated evaluation with suitable uncertainty estimates; deterministic properties such as authorization and schema validity can still use pass/fail checks. This could also be reviewed/analyzed via replaying the work log, but not as a deterministic rerun.
This is also where many initiatives fail economically. Gartner has predicted that over 40% of agentic AI projects will be canceled by the end of 2027, citing escalating costs, unclear business value, or inadequate risk controls. Gartner, 2025, 9
Implication: Without evidence-first operational surfaces, teams either avoid high-stakes workflows or accept a fragile system that cannot be trusted, audited, or improved systematically or are forced to descope to workflows with less risk/value.
A source reference supports a finding only if it identifies the material actually used. A successful tool response supports a completion claim only to the extent that the source system confirms the intended effect. An execution record needs to preserve these distinctions.
1.2.4. Summary
These three constraints define the design and deployment cliff for agentic apps. They also define the platform requirements for moving from demos to operable systems: bounded autonomy, end-to-end governance that travels with the work, and evidence-first operations.
1.3. The first-mile: discovery tax and lost provenance
Agentic app UX and DX does not begin at the time of delegation. It begins right at the beginning, where the system (and the humans building it) must discover, verify, and structure the material that will later ground agent behavior.
In any knowledge work environment, the first-mile is dogged by persistent taxation:
Discovery tax: finding the right material across the sources of knowledge - sites, files, and integrations.
Context and knowledge capture: if provenance and structure are lost, everything downstream becomes brittle.
1.3.1. Discovery tax is measurable, and it compounds
Even before generative AI, discovering sources, curating them, and reconciling conflicting information was unavoidable overhead, and it determined the quality of the work product. Today, that same overhead compounds downstream: every gap in context or memory is paid again at agent execution time:
Information sprawl is now the default environment. Gartner’s 2023 report, based on a 2022 survey, reports that 47% of digital workers struggle to find the information or data needed to effectively perform their jobs, and that the average desk worker uses 11 applications (up from 6 in 2019). Gartner, 2023, 10
A material portion of the workday is spent just tracking down information. McKinsey’s 2012 analysis estimates that interaction workers spend 19% of their time trying to track down information (including searching through their own email files). McKinsey Global Institute, 2012, 11
Switching contexts has a real cognitive cost. Research has summarized prior findings that it takes people around 23 minutes on average to resume an interrupted task. Mark et al., 2015, 12
A separate 2016 workplace study found that longer daily time spent on email was associated with lower perceived productivity and higher measured stress. Mark et al., 2016, 13
For traditional knowledge work, this tax is expensive mainly because it directly reduces productivity. For agentic software, it is more dangerous: it changes what the system believes is true, and that belief propagates through every decision and tool call. The result is compounding drift across actions.
1.3.2. Why first-mile failure breaks agentic apps
When discovery is slow and context is fragmented, teams compensate with shortcuts:
They optimize for what is easiest to retrieve, not what is authoritative, current, and permitted.
They encode assumptions in prompts and tribal knowledge instead of in governed, versioned artifacts.
They treat the “knowledge base” as a document pile rather than a system of record with provenance, permissions, and change history.
Those shortcuts may be survivable with humans in the loop who can notice subtle mismatches and correct course. They become harder to contain when the unit of work is agent behavior: an agent may act on incorrect or incomplete information, and dependent steps can inherit the same error.
This yields predictable, compounding failure modes:
Wrong-version worldview: the system retrieves an outdated policy, contract clause, or runbook, and then makes every subsequent decision against the wrong version.
Boundary drift (scope bleed): the boundary was implied rather than enforced, so the system pulls in information outside the intended scope or authorization and uses it to steer actions.
Invisible regressions: the system cannot answer basic operational questions like “Which source and version did this come from?” “Was it authorized?” “What changed since last week?” so behavior shifts silently until it surfaces in outputs or incidents.
Retrieval-augmented generation provides a foundation for combining model generation with retrieved information and showed improvements on knowledge-intensive tasks in the original study. Retrieval alone does not determine organizational authority, access rights or applicability. Those are additional application responsibilities. Lewis et al., 2020, 14
Context selection also matters after retrieval. Lost in the Middle found that the position of relevant information affected performance in the long-context models and tasks studied. The application should test how context selection and ordering affect results on its own tasks. Liu et al., 2024, 15
Figure 2: The compounding effect of first-mile failure
1.3.3. Provenance is the missing connective tissue
To move from “context blobs” to operable agentic workflows, the first mile must preserve provenance.
The W3C PROV standard defines provenance as information about the entities, activities, and people involved in producing a piece of data, used to assess its quality, reliability, or trustworthiness. W3C PROV-O, 2013, 16
Governance bodies are increasingly explicit that traceability and documentation are operational requirements, and NIST’s Generative AI Profile calls out provenance tracking and documentation of origin and history as part of practical risk management. NIST, 2024, 17
Provenance makes inspection possible. Assessing the source’s correctness, authority, recency and relevance requires further evaluation for the task. A supplier’s declaration, an independent verification and an approved policy can all have valid provenance while carrying different evidentiary weight.
1.3.4. Implication: the first-mile knowledge capture must provide governed building material
If agentic apps are to be trustworthy in production, the first-mile cannot end with “we collected some documents.” It must produce governed, referenceable building material.
That requires first-class tooling that create packaged primitives for:
Discovery in-flow: active capture, curation of relevant material as work happens.
Provenance retention: preserve source, time, authorship, transformations, and permissions as metadata attached to captured material (to the extent possible). Maintain the provenance thru any chunking or pipeline processing.
Structure, not just storage: represent knowledge in a way that survives reuse (relationships, boundaries), so downstream agent behavior does not depend on brittle prompt conventions.
Policy-carrying context: ensure that what the system is allowed to know remains attached to the workflow and enforceable later at runtime.
2. Designing for a true agent-first experience
2.1. Designing the agentic user experience
Agentic app UX and DX become delegation-first when the end user delegates an outcome to a system that can plan, take actions, and return a reviewable work product.
That interaction can be:
Embedded agents, fronted by use case-specific UX, where the user may not even realize they are interacting with an agentic system, or
Explicit agent interaction via the now-standard chat interface.
Here are two examples to set context:
Job matching. The user uploads their resume. Specialized agents extract qualifications, standardize them, and hand off to an agent that matches against an available pool of jobs. In this UX, the user interacts with an upload intake form and a few criteria questions and expects to receive jobs they qualify for that fit the criteria they specified. The agent interaction is one or more steps removed from the end user.
Task planning and coaching. The user chats with the agent directly. The system learns their planning and time management style, applies a preferred productivity strategy (for example, habit-based planning), and conversationally lets them manage tasks and calendar entries via integrations. This experience is direct, but it still carries clear UX expectations, especially around actions like creating tasks or scheduling events through integrations.
Two relatively simple delegated outcomes. Creating from scratch and making either one “just work” and trustworthy is much harder than it looks.
To make either example trustworthy in production, a system must ensure:
In-scope: only approved knowledge/tools, with enforced permissions
Evidence-backed: sources and work artifacts are reviewable
Repeatable: replay and regression to detect drift over time
Builders must work through the build experience to create the agent-first systems they can trust - enough to hand off to the end users in the above examples.
The hardest part of agentic UX and DX is to delegate outcomes with boundaries, then review evidence.
In other words, the interface is no longer primarily screens and controls. The interface becomes the delegation flow.
2.2. Designing for the agentic developer experience
The delegation flow is what users experience. The developer/builder experience is what makes that flow safe, repeatable, and supportable in production.
In agentic software, the unit of work is behavior. Builders are not shipping “a chat.” They are shipping a system that plans, acts, and produces artifacts. If boundaries and evidence are not first-class, discovery tax shows up downstream as compounding drift across actions.
An agent-first DX gives builders a clean path from “this works in a demo” to “this stays true in production”:
Define behavior as reusable blueprints, not one-off prompts. Builders need a way to express role, defaults, and guardrails as something that can be versioned and reusable, then instantiate it for specific users or org contexts.
Ground behavior in governed knowledge, not incidental retrieval.
Builders need knowledge organized into explicit domains where policy, provenance, and change history travel with the material, so context is consistent, auditable, and safe to reuse. In practice, this typically requires a graph-oriented representation (entities, relationships, boundaries) that supports downstream lineage, observability, and analysis
Invoke tools through declared capabilities, not ad hoc integrations. Tool use needs explicit schemas, auth, rate limits, and safety metadata so it can be constrained and observed.
Support sensitive actions with approval gates. Delegation requires a clean pattern for “request approval, record decision, continue execution” that the application UX can integrate into.
Make observability part of the build loop. Builders need traces of what happened: retrieval, tool calls, artifacts created, approvals, and outcomes. Not just transcripts.
Treat replay and regression as normal operations. Builders need a way to replay work and measure drift over time as models, prompts, tools, and knowledge change. Non-determinism does not remove the need for regression. It changes how it is expressed.
Note that any of these paths can be materially affected by the underlying model and toolchain. Tool calling reliability, approval gates, and side-effect handling can vary across providers and can change over time, even with the best of intentions and design goals.
This is the builder-side equivalent of delegation: specify outcomes with boundaries, execute within constraints, and return evidence that can be reviewed, corrected, and replayed.
2.3. The delegation loop: the new core interaction primitive
An agent-first system is designed around a repeatable, if not deterministic loop:
Declare the outcome (what “done” means).
Attach constraints (what the system can know and do).
Execute with bounded autonomy (act within enforced limits).
Return evidence-backed artifacts (not just prose).
Review, approve, correct, and replay (iterate safely over time).
This aligns with long-standing HCI lessons: AI-infused systems often violate expectations from traditional UI design, and require explicit patterns for transparency, user control, and correction. Amershi et al., 2019, 18
Horvitz’s mixed-initiative work examines how automated assistance and human control can be combined according to context and uncertainty. It provides a foundation for deciding when an agent should act, ask or return control. Horvitz, 1999, 19
Figure 3: The delegation loop/flow
2.3.1. Prompts aren’t enough: delegation needs a workflow contract
In an agent-first product, the work cannot be defined only by prompts or implied norms. If the system is expected to plan and act, it needs an explicit workflow contract that can be enforced and audited.
A practical workflow contract has six parts:
Outcome: What is the deliverable, and what are the acceptance criteria?
Scope of knowledge: What sources are allowed (and which are disallowed)? What recency requirements apply? What permissions apply?
Action boundaries: Which capabilities (tools, APIs, workflows) can be used? Which actions are allowed to have side effects (send, write, submit, purchase)? Under what conditions, and with what approvals?
Evidence requirements: What must be cited or attached? What intermediate artifacts are required (checklists, diffs, calculations, extracted fields, confirmations)?
Defined artifacts: What work products must be returned, and what structure must each preserve?
Recovery rules: What should the system do when uncertain, blocked, or when sources conflict? Ask for clarification? Escalate? Stop and request approval?
This contract mindset aligns with governance expectations that humans must be able to understand system capabilities and limitations, monitor operation, interpret outputs, and override or stop operation when needed. Amershi et al., 2019, 18
Implication: Agentic UX and DX require product surfaces that make the contract visible and editable, and platform mechanisms that make the contract enforceable at runtime.
2.4. Bounded autonomy is a security and trust requirement, not a feature
A defining property of agentic systems is that they can be steered off course by inputs, tools, or environment. Common LLM application risks include prompt injection and insecure output handling, which can lead to unauthorized actions or downstream exploits once autonomy and tool use are in play. OWASP, 20
Bounded autonomy requires platform-level primitives such as:
Permissioned knowledge access: Enforced identity, role-based access, and scoping so the system cannot scope-bleed into unauthorized sources.
Capability governance by default: Allowlists, capability tiers, sandboxing, rate limits, and explicit classification of side-effect capabilities vs read-only capabilities.
Approval gates: Clear points where execution pauses for review before committing an irreversible action (send email, submit ticket, update CRM, execute purchase).
Safe failure modes
Stop, ask, escalate, or fall back to a safe summary when the contract cannot be satisfied.
This aligns with risk frameworks that treat reliability, transparency, and accountability as design and operational requirements, not only model-evaluation concerns. NIST, 2023, 5
Implication: You do not add safety later. You design autonomy as a bounded subsystem from the start.
Least privilege limits the authority supplied to a task. Complete mediation requires checking access at the point it occurs, including changed authority. These established security principles apply directly to agentic execution. An earlier successful check cannot justify every later action indefinitely. Saltzer and Schroeder, 1975, 21
Approval is useful only when it binds to a reviewable proposal. The user needs the target, proposed effect and relevant evidence. If those change materially, the original decision may no longer cover the action. Sensitive steps such as sending a message, modifying a business record or placing an order require the controls appropriate to their consequences.
2.5. Evidence-first operations: upgrade chat logs into work logs
In production, agentic systems need operational evidence that answers:
What happened?
Why did it happen?
What can change to influence the outcome?
Would it happen again after changes?
An agent-first system therefore must produce work logs: structured evidence aligned to the workflow contract, not just chat transcripts.
Capability calls, intermediate transforms, decision points, and constraint application.
Artifacts (what was produced)
The deliverables and intermediate work products, not just final text. This excludes internal model reasoning and any opaque, non-inspectable steps inside the model.
Implication: Evidence is not a debug mode. It is part of the user experience and the operational contract.
2.6. Replay and regression: Continuous Integration (CI) for agent behavior
Agentic systems change even when you think they don’t. Models update, capabilities change behavior, knowledge sources drift, and policies evolve. Without replay and regression, “it worked last week” becomes unprovable.
Delegation-first systems need regression primitives:
Replay-able runs: Re-run the same workflow with the same inputs and constraints, then compare artifacts and evidence.
Eval harnesses tied to acceptance criteria: Evaluations are widely recognized as essential for reliability, especially when upgrading models or changing system components. OpenAI, 22
Documented test sets and methodology: Risk frameworks emphasize pairing accuracy measurements with representative test sets and documenting methodology. NIST, 2023, 5
Implication: If the unit of product is agent behavior, then evaluation and regression become the equivalent of unit tests and CI in software engineering.
Agent evaluation also needs the resulting state and consistency across trials. τ-bench evaluates tool-agent-user interactions against domain policies and an annotated final database state, and introduces a repeated-trial reliability measure. Its results concern the systems and tasks tested; the broader methodological lesson is to assess completed work and repeated behavior. Yao et al., 2024, 23
Regression suites should include ordinary tasks and cases that challenge the contract: a revoked permission, an ambiguous entity, conflicting evidence, an interrupted operation or a rejected approval. Exact checks establish mechanically verifiable properties. Semantic criteria require suitable review and measurement. Section 3.6 develops the distinction between reconstructing a recorded run and rerunning work under controlled conditions.
2.7. The platform consequence: interoperability and governance surfaces are converging
As agentic systems move from prototypes to production, connector standards and governance surfaces are converging, which raises the bar for what “shippable” means:
Interop standards are forming
MCP is an open protocol intended to standardize integration between LLM applications and external data sources and tools. MCP specification, 2025-06-18, 24
Enterprise platforms are adding governance and evaluation
Major platforms are expanding agent governance and maker-to-admin surfaces to support production usage. Microsoft, November 2025, 25
Implication: These developments support the architectural case for connecting authoring, execution, observation and governance. IKE proposes shared contracts for that continuity, with evidence and oversight available throughout the work.
3. The Integrated Knowledge Environment
Agentic knowledge work systems do not fail because teams cannot assemble a model, retrieval, and a tool runtime. They fail because those parts do not, by themselves, produce an operable system where constraints and evidence stay attached end-to-end.
An Integrated Knowledge Environment (IKE) is proposed as an environment layer that makes the following responsibilities part of application design and operation: governed scope and permissions, contract-governed execution, evidence-first work logs, and replay/regression over time.
It is the end-to-end platform that turns agent primitives and underlying infrastructure into shippable, governable agentic apps where outcomes are delegated with boundaries, actions are executed with bounded autonomy, and results return as evidence-backed artifacts that can be reviewed, replayed, and regression-tested over time.
IKE is also a deliberate riff on modern IDEs: an “IDE for knowledge work.” Where an IDE makes code editable, runnable, debuggable, and testable, an IKE makes knowledge capturable with provenance, governable as building material, and usable in agentic workflows that operate safely in production.
The agentic app is the unit that turns these platform capabilities into domain work. It connects the relevant knowledge and methods to the workflow, user experience and acceptance criteria for a particular outcome. The developer experience should let builders see how accepted intent becomes behavior and how a change affects execution, evidence and review. The environment preserves the shared contracts for knowledge, authority, execution and evidence; the application determines how those contracts express the domain’s work. Approved knowledge and methods can support several applications within their permitted scope, and an application can evolve without losing the basis for earlier decisions.
3.1. Definition: what an Integrated Knowledge Environment is
An IKE is an environment-shaped platform for building and operating delegation-first agentic apps. It defines a clean separation of concerns:
Builders and their applications own the user experience, user identity, and business logic.
The IKE provides the runtime boundary that governs authorization, knowledge scope, tool use (including downstream integration auth), and operations per end-user context.
3.1.1. Deployment and isolation model: applications, tenants, environments
An agent-first system must prevent context bleed across customers and across lifecycle stages. An IKE therefore assumes:
Each customer or org maps to an isolated, tenant-scoped runtime boundary containing that tenant’s behavior definitions, governed knowledge, integrations, policies, and telemetry.
Each tenant boundary supports multiple environments (for example dev/staging/prod or regional variants) so teams can iterate safely and promote changes intentionally.
Isolation must hold throughout the data path. Retrieval, indexes, caches, sessions, artifacts and tool credentials all need the correct tenant and environment context. Interface filtering alone cannot establish that boundary. Tests should include attempts to retrieve or reuse material across tenants and environments.
A logical boundary can be implemented through shared or dedicated infrastructure. Each choice must satisfy the required isolation, resource controls, data placement and recovery behavior.
Promotion between environments should identify the versions being promoted and the checks that support the change. Test credentials and sample data must remain distinguishable from production authority and records. Operational evidence should retain the environment in which it was produced.
3.1.2. The cooperating planes inside the environment
Within a tenant boundary, an IKE organizes the system into five cooperating planes:
Agent plane (behavior + collaboration): reusable agent blueprints define role, instructions, defaults, and guardrails; those blueprints can be instantiated into personalized agents for specific users or org units. Complex outcomes are achieved by coordinating multiple agents with defined roles and collaboration policies, rather than overloading a single monolithic agent.
Knowledge plane (grounding + memory): knowledge is organized into governed domains with shared indexing and policy. External sources are transformed into structured, queryable knowledge objects via ingestion pipelines that normalize, chunk, and index content. Knowledge is explicitly multimodal (text, images, audio, video), and modality remains a first-class attribute, so it stays retrievable and auditable.
Capability plane (tools + integrations): agents invoke declared capabilities that wrap APIs, internal services, and workflows with explicit schemas, auth, rate limits, safety metadata, and modality constraints.
Some capabilities are designed to produce durable knowledge artifacts and may be persisted, while others are ephemeral (used only to answer the current question or make the current decision).
Execution and interaction plane: coordinate work, decisions, state and recovery while preserving the task’s identity and accepted scope across steps and interruptions.
Operations plane: record activity, inspect outcomes and evaluate changes, connecting behavior and artifacts to their source and definition versions.
Cross-cutting these planes are two properties that must be native, not bolted on:
Governance: policy-controlled boundaries for what can be read, written, and executed, including approval gates for sensitive actions and possible chain of custody records.
Observability: a universal record of agent-work as structured events and traces, supporting auditability, debugging, replay, and analytics.
3.1.3. Runtime modes
An IKE supports both:
Interactive execution: real-time delegation in interactive threads (human <-> agent), and collaboration channels (multi-agent + human).
Background execution: batch workflows such as ingestion, reindexing, periodic analysis, and scheduled runs.
For sensitive actions, an IKE provides built-in approval gates so applications can require explicit review before an agent proceeds.
A shared runtime can serve bounded requests or sessions. A persistent hosted runtime can support a framework’s longer-lived sessions, tools and background activity. Direct execution and hosted frameworks such as OpenClaw are possible execution substrates beneath the same application-level contracts.
The choice affects isolation, state ownership, resource use and recovery. A runtime adapter must establish how task scope, credentials, cancellation and evidence cross the boundary. It also needs a defined response when the underlying runtime cannot preserve a required property.
3.2. The right platform shape: environment continuity across UX and DX
A useful way to frame the platform shape is simple: agentic software needs more than capabilities. It needs continuity across both the developer experience and the user experience after deployment.
In conventional software, teams can often separate build-time intent (requirements, specs, tests) from run-time operations (logs, monitoring, incident response). In delegation-first workflows, that separation breaks down because:
The unit of design is behavior under uncertainty, not deterministic code paths.
Policies and boundaries must be enforced during execution and output generation, not remembered by humans.
Operators need workflow evidence, not just transcripts.
The “environment” platform shape is intended to support this continuity through shared surfaces for capture, governance, execution, oversight, and improvement. Applications use those surfaces while defining their own domain meaning, working methods and acceptance conditions.
3.2.1. Analogy using the Stripe payment journey
On Stripe-enabled checkout pages, the last-mile moment is a straightforward interaction: click “Pay.” Stripe’s value is not just enabling that click. It productizes the end-to-end journey around that “simple” flow for both UX and DX: validation, retries, failure handling, risk controls, reconciliation, and operational visibility. It also absorbs real-world dependencies like processor integrations, contractual rails, and jurisdictional requirements. The developer integrates a small surface area, while the platform absorbs the complexity that makes payments real in production.
A checkout may present a simple payment action while the implementation tracks a longer lifecycle. Stripe’s Payment Intents API models that lifecycle through payment states, including transitions that require further action or authentication. The visible interaction depends on managed state and a defined integration contract. Stripe, 26
Agentic knowledge work has the same shape. The visible moment is a user delegating an outcome (“do this work”), but the system only becomes trustworthy when the end-to-end UX journey (and the DX to create the experience) is critical to get right:
Agentic UX (the delegation loop): explicit scope, boundaries, approvals, evidence-backed artifacts, and recovery paths.
Agentic DX (the embedding and building loop): a small integration surface and workflow contract that mechanically carries provenance, permissions, tool governance, audit-grade traces, and replay and regression over time.
The architectural goal is a compact integration surface for these shared contracts. Application teams still define domain meaning, prepare mappings and establish acceptance criteria. That work must be included in the evaluation described in Section 6.
3.3. The minimum surfaces an IKE must expose
To make delegation shippable, an IKE must expose a small set of end-to-end surfaces that align with the lifecycle assuming it has the necessary control and access rather than operating as a controller/integration with an opaque external system:
Capture and ingest: turn scattered context into governed knowledge objects with provenance.
Configure behavior: define agent blueprints, collaboration policies, defaults, and guardrails.
Define boundaries: express knowledge-domain policy, capability allowlists, and approval rules as enforceable constraints.
Execute and interact: run interactive threads, collaboration channels, and background workflows with bounded autonomy.
Return artifacts: produce evidence-backed work products, not just prose.
Record and observe: write every meaningful step into an event ledger, grouped into traces.
Replay and regress: rerun work against the same constraints and compare behavior over time.
Embed: provide a developer surface (an ADK) so applications can invoke runs, receive events, and respond with decisions without bespoke glue.
This is what it means for constraints and evidence to travel end-to-end: the same objects that define intent and boundaries also govern execution and produce the record needed to operate safely.
Each surface must define what it returns to the next. Capture returns usable references. Execution returns observed results and unresolved states. Review returns a decision tied to the proposed work. Evaluation returns evidence about the criteria it tested.
These returns preserve intent across components and help locate a failure: a source could not be resolved, a permission was denied, a tool returned an uncertain result or an artifact failed its acceptance checks.
3.4. The Knowledge and Integrations plane: from documents to governed building material
IKE assumes the first-mile outputs more than documents and source data. It assumes knowledge must become referenceable building material, with the metadata and structure required to safely shape downstream behavior: provenance, permissions, scope, indexing, definitions, and relationships.
This is the difference between a “knowledge base” and knowledgeware: knowledge packaged with provenance, permissions, and boundaries so it can safely shape downstream agent behavior.
A knowledgeware package can include definitions, source references, relationships, methods and acceptance examples. It has an owner and a version that can be reviewed.
3.4.1. Agentic UX and DX starts with the first-mile
The first-mile dominates knowledge work because:
Discovery tax: finding and reconciling the right material is slow across tabs, files, portals, and sites.
Context capture: if provenance and structure are lost, everything downstream becomes brittle.
Downstream compounding: gaps in what the system can reliably reference become drift across actions, not just slower work.
IKE treats this as a systems problem: the environment must make it natural to capture and structure knowledge in-flow, so it remains usable building material for later delegation.
The useful unit is determined by the work. A policy clause may require its definitions and exceptions. A financial table may require its units, reporting period and row relationships. A diagram may require the associated explanation. The application should test whether retrieval preserves enough context for the intended interpretation.
Preparation also records distinctions that users otherwise repeat. Which source governs this question? Which date determines applicability? Does a reported status describe an observation, a pending request or an accepted decision? Answering these questions once can support reuse, provided the answer is maintained.
The architecture therefore needs a path from captured material to reviewed domain knowledge. Candidate interpretations remain attributable to their evidence. Acceptance, correction and retirement create a history that later applications can inspect.
3.4.2. Provenance is a foundational element
Provenance answers: Where did this come from, who produced it, what transformed it, and when? The W3C PROV family formalizes provenance as entities, activities, and agents to support assessing reliability and trustworthiness. W3C PROV-O, 2013, 16
In IKE, provenance is not an optional annotation. It is part of the data model.
W3C PROV-DM describes provenance through entities, activities and agents, with relationships such as derivation and attribution. This model connects an artifact to the material and activity that produced it. PROV-O provides an ontology representation of that model. W3C PROV-DM, 2013, 27W3C PROV-O, 2013, 16
In an IKE application, the chain might connect a source document to an extraction, a finding, a review decision and a final assessment. Each link should describe an observable relationship. A source being present in a model’s context is different from a verified finding being supported by a particular passage.
Versioning is essential to that record. A reference to “the policy” is inadequate if the policy changes. The application needs a source version, snapshot or other durable identifier sufficient to establish what was used, within the applicable storage and retention rules.
Provenance also supports correction. When a source or interpretation changes, dependency relationships can identify material that may require reassessment. A dependency record establishes a reason to inspect an artifact; the application owner still decides whether its conclusion remains valid.
3.4.3. Governance must be attached to knowledge
For enterprise knowledge work, “what the system is allowed to know” is as important as “what it can retrieve.” IKE therefore treats knowledge objects as policy-carrying: boundaries, permissions, scope, and sharing rules travel with the material.
This aligns with risk-management guidance that treats trustworthiness properties (validity, reliability, transparency, accountability) as operational requirements, not after-the-fact documentation. NIST, 2023, 5European Commission, 6
Implication: the knowledge plane is a governed substrate for behavior, not a pile of context blobs.
Execution authority comes from the task contract and the application’s policy. Instructions embedded in retrieved material remain subject to those controls. Permission to read a source and permission to send its contents to an external service require their respective checks.
Derived material needs an appropriate access and delivery boundary. A summary may expose restricted facts even when it omits the original wording. Retention, deletion and downstream reuse therefore need explicit treatment in the knowledge lifecycle.
Memory follows the same principle. Session memory holds the state and observations of a particular task. Reusable domain knowledge has a broader scope and acceptance process. Promoting a task-specific inference into shared knowledge should be a reviewable transition with an owner, evidence and version.
Figure 4: Knowledge as building material
3.5. The Execution and Interaction plane: workflow contracts and bounded autonomy
In delegation-first systems, prompts are insufficient as the primary “programming surface.” An IKE formalizes work as a workflow contract that is visible, editable, enforceable, and auditable.
3.5.1. The workflow contract: enforceable intent
The workflow contract introduced in Section 2.3.1 carries six elements into execution:
Outcome and acceptance criteria (what “done” means)
The purpose is not bureaucracy. It is to make delegation safe: the system can act, but only within explicit, enforceable limits, and it must return artifacts that can be reviewed.
The application should preserve the identity of the task across model calls, tool calls and human decisions. A resumed step needs to know which contract it is continuing, which work remains valid and what condition permits it to proceed.
Some elements can be checked mechanically. The source belongs to the tenant. The capability is allowed for the acting principal. The proposed write targets the approved record. The returned artifact contains the required fields and references.
Other elements require judgment. Evidence may be incomplete, a policy exception may be ambiguous or the requested outcome may conflict with a constraint. The contract should identify the responsible decision and the permitted response to uncertainty.
Changes to the route through a task can remain within the accepted contract. A new objective, broader data scope or materially different external effect may require a revised agreement. Completed valid work should remain available while that decision is resolved.
3.5.2. Tool governance is part of execution
Because agentic systems can be manipulated through inputs and can misuse tools if not bounded, an IKE assumes tool invocation and output handling are governed execution concerns. The OWASP Top 10 for LLM Applications highlights risks like prompt injection and insecure output handling, which become acute when systems can act through tools. OWASP, 20
Implication: bounded autonomy is an execution design requirement, not an add-on.
A capability contract should identify the operation, input and output schemas, business meaning, acting authority, destination, effects and failure states. It should distinguish a proposed change from a committed change and an acknowledged request from a completed operation.
Tool results require validation and interpretation. They can contain malformed data, stale state or hostile instructions. AgentDojo evaluates attacks embedded in external data against tool-using agents and demonstrates failures in the systems studied. Its relevance is the need to test the complete interaction between untrusted inputs and permitted capabilities. Debenedetti et al., 2024, 28
The environment must enforce access and effect limits outside model interpretation. Credentials should remain with the component responsible for the integration. The model receives the information needed to perform the task, while the execution boundary applies the authorization required for the actual operation.
These controls must also consider combinations of permitted actions. Separate reads and writes can create an unintended disclosure or effect when composed. The application’s threat model should examine the resulting information flow and workflow.
3.5.3. Known procedures and bounded judgment
Knowledge work contains both known procedures and questions that require interpretation. Calculations, identifier checks and defined state transitions can run as software. Determining whether a passage satisfies a requirement may need a model or human reviewer.
The architecture separates these responsibilities at the level of the task. A prepared workflow can specify dependencies and acceptance checks while assigning particular judgments to a model. An investigation can allow the agent to choose its next source within a defined scope, effort limit and stopping condition.
Anthropic’s engineering guidance distinguishes predefined workflows from agents that direct their own processes and recommends choosing complexity according to the task. That distinction helps determine which steps to prepare and which to leave to runtime planning. Anthropic, 2024, 29
A model judgment should have a defined question, relevant evidence and an expected form of answer. The caller must know what to do with each result, including unresolved or insufficient-evidence outcomes. Confidence thresholds require calibration against accepted examples; a reported confidence score alone cannot establish reliability.
External verifiers can check properties that have a formal representation. Gundawar and colleagues evaluate an LLM-Modulo architecture across scheduling domains, combining model proposals with sound verifiers. Its guarantees depend on the constraints represented and the verifiers used. This supports a bounded pattern of proposal and validation for those properties. Gundawar et al., 2024, 30
Semantic adequacy still requires its own checks. A schema can establish that a finding contains a source reference. Whether that source supports the finding is a separate question. Application acceptance needs to cover both.
3.5.4. Durable execution and recovery
A task may outlive a browser connection, wait for a person or depend on work in another system. Durable state should preserve the accepted contract, completed steps, outstanding dependencies and the next permissible action.
Useful states include proposed, ready, running, waiting for a decision, completed, failed and cancelled. Their exact representation is an implementation choice. Each transition needs a condition and the evidence that establishes it.
External effects make recovery more demanding. A request may time out after the receiving service has committed the change. Repeating the request can duplicate the effect. The Amazon Builders’ Library describes using caller-supplied request identifiers and idempotent API contracts to make retries safe within the service’s defined semantics. Featonby, 2021, 31
Where an integration supports that contract, execution should preserve and reuse the appropriate operation identity. Elsewhere it may need to query current state, reconcile the outcome or ask a responsible person to resolve an uncertain result. Automatic retry requires evidence that retrying is appropriate.
Cancellation also has limits. It may prevent future steps while an external operation is already committed or still completing. The work record must distinguish the cancellation request from the observed state of affected operations. A compensation, where available, is a further action with its own authority and possible failure.
3.6. The Operations plane: evidence, event logs, replay, and regression
IKE treats “ops need evidence” as a primary plane: lineage explains why, artifacts show what, and regression is how the last-mile stays true.
3.6.1. Evidence-first operations
Evidence answers three operator questions:
What happened? execution trace, capability calls, decisions, approvals
Why did it happen? lineage to sources, constraints applied, conflict resolution
Would it happen again? replayability and regression checks
Regulatory direction reinforces these operational needs. For high-risk systems, the EU AI Act includes expectations around record-keeping (automatic logging) intended to support traceability and oversight. AI Act, Article 12, 7
A useful work record identifies the contract, relevant definition versions, selected sources, capability invocations, decisions and resulting artifacts. For external effects, it preserves the receipt and the observation used to establish the resulting state.
Evidence has limits. A trace can establish that a tool was called and what it returned. It cannot, by itself, establish the correctness of an interpretation. A model’s explanation can help a reviewer understand a proposal, but it needs checking against the supporting material.
Chen and colleagues found that reasoning models could use hints without reliably acknowledging their use in reasoning traces. Their experiments illustrate limits on treating those traces as a complete account of model behavior. IKE’s work record captures inspectable observations, decisions, actions and artifacts. Chen et al., 2025, 32
Different readers need different access. Operational traces can contain sensitive inputs or outputs, so collection, redaction, retention and access controls must be designed alongside instrumentation. The required evidence should be sufficient for the task’s review and accountability needs.
3.6.2. Observability is converging toward standards
The ecosystem is starting to standardize how GenAI systems are observed. OpenTelemetry semantic conventions for generative AI define signals for model and agent operations (events, metrics, spans), reinforcing that “agent ops” is becoming a real discipline with shared instrumentation patterns. OpenTelemetry, 33 Implementations need to track the convention version because these specifications are under development.
Application records supply additional meaning: the task, policy, artifact, acceptance criterion and decision associated with an event. A model-call span can measure duration and usage; a work record connects that call to its role in the task.
Correlation identifiers should connect these views without forcing every reader to inspect raw telemetry. Operators need to move from a failed outcome to the relevant steps, source versions and external observations.
3.6.3. Replay and regression are “observability for behavior”
Because agent behavior drifts with model updates, capability changes, and knowledge evolution, an IKE includes:
Replayable runs: same inputs, same constraints, comparable artifacts
Regression suites: tied to acceptance criteria, expressed as tolerances and confidence (not exact string matches)
Change tracking: across knowledge, tools, and behavior
Implication: reliability becomes an engineering practice, not luck.
Replay has two meanings. A recorded run can be inspected to reconstruct events. A task can also be rerun under controlled conditions to compare behavior. The first requires a sufficient history; the second requires an explicit account of the conditions being reproduced.
A comparison should identify the source snapshots, workflow definitions, model configuration, tool responses and acceptance criteria held constant. Repeating a task against live systems may encounter changed records or permissions. That is evidence about current operation, with different interpretation from a controlled regression.
External effects need suitable test boundaries. Recorded responses can help isolate a decision path. A test environment can exercise an integration. Operational verification establishes behavior at the real boundary. The evidence from each should retain its scope.
Evaluation should cover the outcome, the permitted path and recovery. Deterministic checks assess fields, calculations, identifiers, authorization and observed state changes. Semantic review assesses support for findings, preservation of qualifications and usefulness to the intended reader.
Model-based judges can extend coverage, subject to their own evaluation. Zheng and colleagues identify position, verbosity and self-enhancement biases in LLM judging. Calibrating judges against reviewed examples and investigating disagreements helps establish where their scores are useful. Zheng et al., 2023, 34
Results should report the cases tested, trial counts, accepted outcomes, incomplete work and boundary failures. Repeated sampling is useful where behavior varies. Statistical claims require a defined population and a suitable method; exact policy checks retain their own pass or fail outcomes.
Knowledge and workflow changes belong in regression alongside model changes. Dependency records can identify affected scenarios. The NIST Generative AI Profile’s lifecycle treatment of testing and monitoring supports this approach, while application-specific evidence establishes its effectiveness. NIST, 2024, 17
Figure 5: Work logs vs. chat logs
3.7. Interoperability and the Agent Development Kit: reusable agentic DX
An IKE assumes knowledge work is multi-system: documents, ticketing, CRM, warehouses, policy systems, internal wikis, and more. To avoid bespoke integration per workflow, an IKE needs two complementary developer primitives: interoperability and an Agent Development Kit (ADK).
3.7.1. Interoperability: connecting tools and context without bespoke glue
Interop protocols can standardize how agentic systems connect to external data sources and tools. The Model Context Protocol (MCP) is an example of an open protocol intended to standardize integration between LLM applications and external systems. MCP specification, 2025-06-18, 24
For example, a technically valid update call may acknowledge queued work while the business record remains unchanged. The integration must preserve that distinction so execution can decide whether to wait, verify or recover.
Agent-to-agent handoffs need the same care. A receiving agent needs the delegated outcome, relevant evidence, bounded authority and a return contract. The caller remains responsible for evaluating the returned work before dependent actions proceed.
3.7.2. The ADK: embedding and shipping agent-first behaviors
Interoperability is the “connect” DX and the ADK is “ship” DX.
An ADK is the developer experience that makes it straightforward to embed delegation-first behaviors into applications and enterprise environments with minimal bespoke glue. Conceptually, it provides:
SDK/API: the primary surface for embedding delegation loops into applications
Hooks: lifecycle hooks for approvals, evidence capture, escalation, and side-effect gating
Modules: reusable building blocks for common needs (for example authentication and authorization)
Integrations: a consistent way to connect capabilities and context (paired with interop standards where possible)
Packaging and versioning: so that behavior definitions remain reusable as teams and models change
Governance and observability defaults: so that integrations inherit boundaries, traces, and replay/regression without re-implementing them per app
The ADK is intended to make integration contracts reusable across applications. A compact API may reduce repeated integration work. Application teams still define domain meaning, review behavior and acceptance conditions. The net effect on development and maintenance effort requires measurement.
A compact integration surface is valuable when its semantics remain clear. Developers still need to know which component owns task state, how a decision resumes work, what an event guarantees and how completion is verified.
Through the ADK, builders use IKE’s knowledge, execution and operational contracts to create Agent Applications. Each application applies those contracts to a particular kind of knowledge work, with its own domain concepts, working methods and acceptance criteria. Its behavior and the interactions through which people delegate, inspect and correct the work have to be designed together.
4. From domain knowledge to Agent Applications
A delegation-first user experience lets a person express an outcome, establish boundaries and review the resulting work. Supporting that experience requires a developer experience organized around accepted intent, domain meaning and observable behavior. The environment’s contracts therefore need a method for turning domain expertise into an application that carries those expectations through execution and review. Documents supply part of the input. Subject matter experts also contribute the distinctions, methods and exceptions that determine whether work is acceptable.
This development model builds on knowledge representation, mixed-initiative interaction and the separation of model proposals from external checks. It carries meaning through a sequence of reviewable representations: domain definitions, human-owned intent, derived annotations, capability and interaction mappings, workflow composition and acceptance evidence. Builders can trace a requested outcome into application behavior. Users can review that behavior against the intent they accepted.
The model uses four related representations. The semantic graph defines domain concepts and relationships; the knowledge graph holds source-grounded entities and assertions used in the work. The product graph describes supported capabilities and interaction contracts. The saved intent graph represents accepted outcomes and their dependencies. Links between these representations connect meaning, evidence and behavior while preserving what each representation is responsible for.
4.1. Shared meaning and domain models
A domain vocabulary identifies the concepts that matter to the task. An ontology makes selected relationships explicit: a supplier has contracts, an assessment concerns a supplier, a finding is supported by evidence and an approval is performed by an authorized role.
Gruber’s work on portable ontology specifications provides a foundation for sharing explicit concepts and relationships across systems. These shared meanings guide knowledge preparation, application composition and evaluation. Gruber, 1993, 35
That agreement has to reach the operations the application performs. “Approve an assessment” needs a defined subject, responsible role, prerequisites and observable result. An API field called “status” supplies a representation. The domain model defines what its values and transitions mean.
The model can begin with one bounded workflow. It should grow where ambiguity affects behavior, reuse or acceptance. If two teams use “approval” for different events, the disagreement must remain visible until the responsible owners establish the distinction.
A semantic graph makes agreed domain concepts and relationships explicit: how an assessment relates to a supplier, how evidence supports a finding and which roles may approve a result. Applications use these definitions to interpret the work and inspect its dependencies. This representation is separate from the physical storage of the underlying material. Documents, relational records, vector indexes and graph stores can serve complementary purposes. Meaning must survive movement between these stores and remain available for execution and review. That requires shared identifiers and consistent semantics.
The knowledge graph must connect these definitions to particular entities, assertions, evidence and decisions. A supplier, a policy clause and a finding each need a stable identity. Typed relationships express what each connection means: an assessment concerns a supplier, a passage supports an assertion, a finding evaluates a policy requirement and a decision accepts or rejects a finding. Shared domain definitions describe these types and relationships; governed knowledge and work records hold the particular instances, their versions and their permitted scope.
Capture and interpretation produce candidate assertions and relationships. Each candidate should retain its source passage or record, source version, relevant entity identifiers, applicable time and scope, and the activity that produced it. Entity matching must distinguish a confirmed identity from a possible match. Validation and the required acceptance decision determine how an assertion may be used. A source’s claim, a model’s interpretation and an accepted finding remain distinguishable, with conflicts and unresolved evidence visible. An extraction score alone cannot establish truth or authorize action.
During application preparation, these relationships connect domain requirements to the kinds of evidence, decisions and capabilities the work needs. During execution, the selected case supplies the actual entities and records. Traversing their permitted relationships helps locate applicable policies, supporting passages, conflicting assertions and outstanding decisions. The application uses those results to assemble context, determine which prerequisites are satisfied and present the basis of a finding for review. Access and action checks still apply when material is retrieved or an effect is requested.
Provenance records connect each interpretation and result to the inputs, activities and responsible actors that produced it. W3C PROV models these links through entities, activities and attribution relationships. The application supplies the domain meaning and acceptance rules, including who may confirm a finding and how that decision is recorded. W3C PROV-DM, 2013, 27
4.2. Human-owned intent and acceptance scenarios
Subject matter experts explain how the work is conducted and judged. Examples of incomplete or rejected work often reveal acceptance boundaries that successful examples leave implicit. An unsupported conclusion, an overlooked exception or an incorrectly matched record can each become a scenario for the application.
Human-owned intent describes the desired outcome using the domain vocabulary. A useful scenario identifies the starting conditions, the action or event and the observable result. Related scenarios cover missing evidence, conflicting policies, insufficient authority and partial failure.
For a supplier assessment, one scenario may require a draft with an evidence reference for every finding. Another may require an unresolved policy conflict to remain visible while withholding the dependent recommendation. Together they establish useful progress and an acceptable stopping condition.
Acceptance must also assign responsibility. An automated check may verify reference integrity. A domain reviewer may decide whether the evidence supports a finding. A designated role may authorize an external update. These decisions have different meanings and should produce distinct records.
Before implementation, the contract lets a builder identify what must be represented, which observations count as evidence and where a missing decision prevents further work.
The authoring environment derives annotations that connect accepted intent to domain concepts and supported application contracts. These annotations form a separate, generated interpretation of the source. Subject matter experts express the desired work and its acceptance conditions in domain language; the environment supplies the technical mappings needed to connect that meaning to an implementation.
The authoring environment uses a model to propose candidate mappings from the confirmed intent, relevant source evidence and current domain and product contracts. Structural checks verify referenced identities, versions and types. Semantic evaluation then tests whether the evidence supports the mapping and whether it preserves the accepted meaning. Model and prompt selection are implementation decisions that require evaluation on representative application cases.
The application must specify which decisions automated evaluation can make and which require a domain or capability owner. For an unresolved or conflicting mapping, retain the question, supporting evidence and decision owner. A calibrated confidence estimate can help route review; acceptance still depends on the applicable checks and authority. Record the generated candidates, corrections and review effort so preparation cost and reuse can be assessed.
Each annotation should identify the source statement it interprets, the evidence supporting the mapping, the relevant owner contract and the interpretation version. An unresolved mapping should remain visible with the decision it requires. Human-confirmed source owns the intended meaning. A conflicting annotation returns for correction against that source, while a proposed change to the intent requires human confirmation. Reviewers can check the translation into application contracts while keeping the expert’s requirement distinct from the generated interpretation.
4.3. Map meaning to capabilities
Composition connects domain operations to the systems that can perform them. A mapping identifies the source system, relevant entity identifiers, input and output meaning, authority, possible effects and expected evidence.
The product graph describes supported application contracts: surfaces, interactions, inputs and outputs, policies, capabilities and their owners. These connections establish how a person delegates work, receives an artifact, inspects evidence, supplies a correction or authorizes an effect.
Mapping intent to this graph connects the review experience to the behavior being reviewed. An approval interaction, for example, needs a defined subject, the evidence available to the reviewer, the authority required for the decision and the capability that can carry out the accepted change. A change to the presentation should preserve those contracts. A change to their meaning or effects requires review against the accepted intent.
Syntactic correctness is one part of the mapping. A valid identifier may refer to the wrong supplier. A successful response may acknowledge a queued request. A returned timestamp may describe ingestion rather than the event the user cares about. The application needs the semantics behind these fields.
Each fact and decision also needs an owner. A source system owns its record state. A policy owner determines the applicable rule. An authorized person accepts an exception. A model supplies an interpretation or proposal within its assigned scope.
A reviewer can use these mappings to trace a requested outcome to its domain operation, the selected capability and the observation expected on return. A missing mapping remains a concrete implementation gap.
4.4. Applications, Personas and execution
An Agent Application provides the user experience for initiating, inspecting and completing work defined by human intent. It owns the workflow’s meaning, business rules and acceptance criteria. The application team supplies that domain meaning and working method. IKE supplies the authoring model, shared representations, interaction contracts and execution mechanisms used to build and evolve the application. Connected systems retain ownership of their records and committed state. Authorized people retain responsibility for substantive acceptance and consequential decisions.
A Persona supplies reusable behavior: a role, instructions, relevant knowledge, capabilities and operating defaults. A Persona Binding connects that definition to an application context. An Agent Application can have zero or more Persona Bindings; its identity and lifecycle are distinct from any individual Persona.
An application session supplies the context for an instance of work, including relevant participants, case material, accepted decisions and progress. The execution runtime performs agent work within that context.
A research Persona can contribute to several applications with different evidence requirements and permissions, while each application retains its own meaning. An application can use a different runtime if that runtime preserves its required controls and lifecycle behavior.
The interaction surface can vary as well. One participant may review an evidence table while another discusses a conflict in chat. Both should refer to the same task, decisions and artifacts.
4.4.1. An AML companion over an existing case system
Consider an anti-money laundering (AML) system that maintains customer records, screening results, information requests and review cases. It already supports knowledge work through its records and workflows. In this illustrative example, a companion responds to the analyst’s opening question: what needs attention now, and why? Its briefing reflects the analyst’s role.
The accepted intent requires a briefing based on the current work assigned to that person, with evidence for each priority and only permitted next actions. The companion gathers the relevant work inventory and retrieves the case evidence needed for the briefing. It should identify missing facts that affect the next decision, distinguish source facts from interpretation and preserve the source version used.
The authoring step maps those requirements to data and capabilities. “My work” maps to the source assignment identity bound to the selected role. A service-level judgment requires the governing policy, relevant timestamps and an as-of time. A suggested action maps to a supported capability, its permissions and the case context that justifies it. The saved dependencies connect those prerequisites to the briefing and the work surface the analyst uses next.
The analyst can inspect the supporting case, question an interpretation or continue from a suggested action while keeping the earlier evidence available. A business change begins as a proposal and follows the required approval and completion checks. The existing case system retains its records and committed state. The agentic app adds a way to gather, interpret and act on that work through a reviewable interaction. Changes to the review method can then be traced into the affected mappings, behavior and acceptance checks.
4.5. Prepare and validate executable work
Builder is the authoring component in this development model. Its role is to use human-confirmed intent and validated annotations to produce a saved intent graph: a directed acyclic graph that preserves the accepted outcomes and their dependencies. The semantic graph supplies agreed domain meaning. The product graph supplies supported capability and interaction contracts. Each part of the intent graph retains its connection to the source requirement and the mappings used to interpret it.
Figure 6: From intent to executable behavior
Preparation is intended to resolve work that would otherwise be repeated during every run: identifying relevant contracts, connecting accepted requirements to supported capabilities and interactions, establishing dependencies and defining checks. The represented outcomes and dependencies must remain traceable to confirmed intent and its validated mappings. This provides a stable basis for execution and review while retaining the source of each requirement.
The dependency graph identifies work that can proceed independently and work that requires an earlier result. Within the declared scope, permissions and acceptance conditions, runtime planning can choose concrete tools, components and case-specific steps as observations arrive. A human requirement for a particular supported capability remains binding. Repeated investigation can occur inside a bounded step, with a defined stopping condition. The representation should make the task easier to execute and verify.
Validation occurs at several levels. Structural checks examine references, schemas and dependencies. Policy checks examine data access and allowed effects. Semantic review checks whether the proposed workflow expresses the accepted intent. Runtime evaluation then establishes what the application actually does.
Across these representations, structural checks verify that identifiers and versions resolve, relationship endpoints have the required types, and each required mapping has a recorded review status. A review status records the decision; evidence and semantic evaluation are needed to justify the interpretation. Acyclicity applies to the saved intent dependency graph; domain and product relationships may contain cycles. Scope checks verify that the referenced knowledge and contracts belong to the permitted tenant and application context. Semantic review determines whether the evidence supports an interpretation and whether the mappings preserve accepted intent. An unresolved required mapping pauses the work that depends on it; independent work may proceed. A recorded approval relationship identifies a decision and its scope; execution still checks the current authority for the particular action.
Generated work remains a proposal until the appropriate checks and acceptance decisions are complete. Each step needs a reason to exist in the requested outcome, a defined input and an observable contribution. Unresolved meaning or missing capabilities should retain an owner.
4.6. Change and promotion across the lifecycle
Domain definitions, source interpretations, workflow steps and capability mappings evolve at different rates. Versioning allows a candidate change to be reviewed against the consumers and scenarios it affects.
Reusable methods, organization-specific policy and case evidence also have different scopes. A general method may be shared across deployments. A customer’s interpretation belongs to that customer’s context. Evidence from one investigation remains within its case boundary unless an authorized promotion establishes broader use.
A recurring finding can suggest an improvement to the shared method. The application should preserve the supporting examples and propose the change for review. Acceptance creates a new version that can be evaluated against both existing scenarios and the cases that motivated it.
Historical work retains the assumptions under which it was accepted. A changed policy may require reassessment of some results while others remain valid historical records. The dependency model helps identify candidates for review; the responsible owner decides their disposition.
That review begins with the identity and version of the changed item. Following recorded dependency links identifies the interpretations, annotations, application contracts, intent nodes and work results that used it. The links show why each item is a candidate for reassessment; the responsible owner determines whether its meaning, applicability or acceptance has changed. An accepted correction leads to a new version and evaluation of the affected behavior. Earlier work remains linked to the sources, definitions and decisions used at the time.
Preserving the connections between accepted intent, executable behavior and operational evidence lets an application improve without losing the basis for earlier decisions.
4.7. Summary: what IKE enables
The preceding sections defined an Integrated Knowledge Environment as the environment layer that turns agent primitives into an operable system where constraints and evidence stay attached end-to-end. They described the platform shape (continuity across UX and DX), the deployment model (tenant isolation and environments), and the cooperating planes (agent, knowledge, capability, execution and interaction, and operations) with governance and observability as native properties.
Concretely, an IKE enables:
End-to-end continuity: consistent surfaces for capture, governance, execution, oversight, and improvement, rather than rebuilding them per workflow.
Application behavior grounded in intent: human-confirmed requirements and domain meaning guide the design of behavior and user interactions, with annotations and graphs preserving the connections for review and change.
Governed knowledge as building material: knowledge is captured and ingested with provenance, then governed with permissions and boundaries so it can safely shape downstream behavior (knowledgeware, not a document pile).
Bounded autonomy through workflow contracts: delegation is formalized as an enforceable workflow contract that defines outcomes, scope, action boundaries, evidence requirements, artifacts, and recovery rules.
Evidence-first operations: agent work is recorded as structured events and traces, so outcomes are auditable, debuggable, and explainable beyond chat transcripts.
Replay and regression over time: runs can be replayed and compared against acceptance criteria, so drift from model, capability, or knowledge changes becomes measurable and manageable.
Snippet-level integration: interoperability plus an ADK reduce bespoke glue by providing a small integration surface for embedding delegation workflows, receiving events, and responding with approvals and decisions.
Those outcomes depend on the contracts holding across the complete lifecycle, including the translation of domain expertise into application behavior.
5. Worked example: a supplier assessment
Consider an illustrative application that prepares a supplier assessment from an organization’s procurement policy, a supplier questionnaire, contract material and prior review records. The user wants a draft with supported findings, unresolved questions and proposed follow-up work. An authorized reviewer decides whether to accept the assessment and update the procurement record.
The example describes the intended behavior to implement and test.
5.1. Prepare the meaning and evidence
Subject matter experts establish what “assessment,” “finding,” “evidence gap” and “approval” mean for this workflow. They identify the policy that governs the assessment and explain which exceptions require review.
The application records the relationship between a supplier and the contracts, questionnaires and assessments associated with it. Integration mappings connect those concepts to the actual record identifiers in the source systems.
Capture preserves the versions and locations of the relevant material. Questionnaire answers remain distinguishable from verified facts. A prior reviewer’s conclusion remains distinguishable from the evidence used to reach it. The policy’s authority and effective period are explicit inputs to the assessment.
Suppose the applicable policy requires evidence of a successful restoration test within the previous twelve months. The supplier questionnaire states that backups run daily, and an older assessment records a restoration test. The application links each assertion to the supplier, its source passage and version, and the period it describes. Daily backups are a reported practice. Whether the older test satisfies the current policy depends on its date, scope and supporting evidence. Until those are established, the requirement for test evidence remains unresolved.
5.2. Accept a bounded delegation
The user selects the supplier and review scope. The contract authorizes access to specified sources and creation of a draft assessment. It defines the evidence required for each finding and reserves the final record update for an authorized reviewer.
For the requirement that every finding carry evidence, a derived annotation links the accepted statement to the domain meaning of a finding and the contracts for presenting and reviewing its support. The semantic graph supplies the meanings of finding, evidence and supplier, and the relationships between them. The product graph identifies the supported evidence display and reviewer interaction. The intent graph retains the evidence requirement and the dependency between preparing the assessment and presenting it for review. These links give the reviewer a path from a finding to its supporting material and the requirement being checked, and give the builder a path for tracing a correction to the affected interpretation or contract.
Figure 7: From evidence to a review decision
For the restoration-test finding, the review surface follows the recorded links from the finding to the applicable policy clause, the questionnaire assertion and the dated test evidence. The reviewer can inspect the source passages, correct the interpretation or request the missing evidence. The accepted intent and its annotations connect this evidence requirement to the supported review interaction; the intent graph makes its resolution a prerequisite for accepting the assessment as satisfying that requirement. The draft can still present the unresolved finding for review. The graph provides a route to the review interaction; the reviewer’s authority and decision are checked and recorded separately.
The prepared workflow identifies known tasks: resolve the supplier identity, obtain applicable material, check required fields, evaluate evidence, assemble the draft and present outstanding decisions. Each task has an expected result and a recovery condition.
The system can carry out independent checks while waiting for a missing document. If a missing item blocks a particular conclusion, that conclusion remains unresolved. The rest of the assessment can still contain useful, supported work.
5.3. Execute and verify
A deterministic check confirms that the questionnaire and contract refer to the selected supplier. A model interprets whether a passage addresses a policy requirement. Its finding records the question considered, the evidence used and any unresolved qualification.
Suppose the questionnaire refers to a control described in an older assessment, while a newer contract changes the relevant scope. The application exposes the conflicting evidence and identifies the decision needed. The conflict becomes part of the reviewable work product.
The draft presents findings with source references and separates evidence gaps from adverse findings. A reader can inspect the supporting passage and see the meaning attached to it. The application’s acceptance checks verify required structure and reference integrity; domain review addresses the substance.
When the reviewer approves a proposed procurement update, the runtime rechecks the target and applicable authority. It records the approved change and invokes the mapped capability. If the response times out, recovery checks the operation’s result using the integration’s reconciliation or idempotency mechanism before continuing.
5.4. Carry the result forward
The completed work record contains the draft, accepted decisions, source versions and the verified external result. A later reviewer can see which policy and evidence supported the assessment at the time.
If the policy changes the restoration-test interval from twelve months to six, the recorded links identify findings that applied the earlier clause and the assessments containing them. The policy owner determines the new clause’s effective scope. The application owner then identifies which assessments need reassessment and which remain valid records of earlier decisions. New work uses the applicable policy version; historical results retain the clause, evidence and acceptance decision used at the time.
A recurring issue may also suggest an improvement to the shared method. That finding becomes a reviewable proposal with supporting examples. Once accepted, it enters a new application version and is evaluated against both the original acceptance scenarios and the cases that motivated the change.
An error in source identity or domain meaning would affect the entire assessment. A missing authorization check would affect the external update. An incomplete work record would make later correction harder. The architecture assigns responsibility for each of those points and defines how its result will be checked.
6. Tradeoffs and tests of the thesis
An integrated environment has costs. It requires maintaining domain definitions, mappings, policies and evaluation material. Recording useful evidence consumes storage and introduces privacy and retention responsibilities. Explicit checks and review points can add latency.
The architecture is best suited to work that is repeated, depends on organizational context, crosses system boundaries or produces consequential artifacts. A narrowly scoped task with a simple acceptance test may need only a small part of the model. The level of preparation and control should follow the task’s ambiguity, consequences and expected reuse.
6.1. Structure must earn its cost
A detailed ontology can become expensive to maintain. A rigid workflow can encode yesterday’s method and frustrate legitimate exceptions. Excessive review can move the entire workload back to the human.
These are design failures to test for. Start with the distinctions required for a bounded task. Add structure when it resolves an observed ambiguity, supports reuse or makes a necessary check possible. Give domain owners a practical way to revise definitions and exceptions.
Prepared workflows also need a defined allowance for runtime judgment. A useful balance preserves known constraints while allowing the system to investigate case-specific questions. The application should expose where the route is fixed, where judgment is permitted and what requires a human decision.
6.2. Integration needs clear failure boundaries
Shared contracts create dependencies between knowledge preparation, authoring, execution and operations. A faulty shared definition can affect several applications. A common authorization service can become a critical dependency. A shared runtime requires careful isolation.
The response is explicit versioning, ownership and failure behavior. Changes should have identifiable consumers. An unavailable dependency should produce a defined state. Tenant and environment boundaries need verification in retrieval, caches, artifacts and tool credentials as well as in the user interface.
Portability also has limits. Models differ in behavior, and runtimes differ in how they handle tools, sessions and recovery. A common adapter can preserve an interface while concealing differences that matter to the application. Conformance tests must cover the behavior required by the delegation contract.
6.3. Measure the claims at application level
The central hypothesis is that redesigning UX and DX around intent, domain meaning, authority and evidence improves the reliability and maintainability of delegated knowledge work. Users should be able to express boundaries, inspect results, correct interpretations and recover control when work diverges. Builders should be able to express accepted intent, inspect its translation into behavior and identify the consequences of a change. Test these claims within a defined application, measuring the quality of the work, the effort required and its cost.
Compare equivalent tasks under controlled conditions while varying one architectural component at a time. Examples include governed source selection versus the existing retrieval baseline; prepared capability mappings versus runtime interpretation of tool descriptions; and versioned workflow preparation versus repeated planning from the same raw material. Include application creation and revision in these comparisons, measuring authoring effort and user control alongside the resulting artifacts.
The comparison needs matched inputs and acceptance criteria, representative exceptions, repeated trials where appropriate and independent review of semantic quality. Record the configuration and the conditions under which the result was obtained.
Useful measures include:
Accepted outcomes: the proportion of tasks meeting the agreed criteria, including adequate evidence.
Boundary failures: unauthorized access, disallowed effects and cross-case or cross-tenant contamination.
Human effort: time spent reviewing, correcting and recovering the work.
Change impact: the effort needed to identify and repair affected behavior after a policy, model or integration changes.
User control: the proportion of representative scenarios in which users successfully express the intended bounds, inspect the relevant evidence, correct an interpretation and regain control after a deviation.
Intent translation: the correctness and effort of expressing accepted intent, tracing it through derived mappings to behavior, and identifying the requirements and contracts affected by a proposed change.
Operational cost: model and tool consumption, latency, retries and support effort per accepted outcome.
Calculate cost per accepted outcome over a defined period: divide all attributable preparation, execution, human review, correction, support and change-maintenance costs by the number of accepted outcomes. Count failed and incomplete runs in those costs. Allocate shared preparation only across applications that reuse it, and record effort by role. Report the first application’s cost separately from the incremental cost of reuse, so the value of preparation can be tested.
Lower model usage alone says little about the usefulness of the system. A more expensive run may produce a substantially better artifact or reduce reviewer effort. Additional orchestration may consume resources without improving acceptance.
If preparation becomes a maintenance burden without improving accepted outcomes, the architecture should be simplified for that task. If semantic quality remains weak despite correct boundaries, the application needs better evidence, methods or model capability.
7. CONCLUSION
This paper argued that agentic apps require more than model capability. The hard part is the system work required to ship, govern, and operate delegation-first workflows in production.
The production cliff is structural. Agent behavior is probabilistic. Constraints must stay attached end-to-end, from first-mile discovery and knowledge capture to last-mile execution and delivery. And operations require evidence: lineage, artifacts, and regression over time.
This is why agentic knowledge work cannot be treated as “chat plus context.” It requires an environment shape that preserves continuity across the lifecycle: provenance-grounded knowledge, contract-governed execution with bounded autonomy, and evidence-first operations that make behavior observable and improvable. This is the motivation for an Integrated Knowledge Environment (IKE) as a system concept: a unified substrate spanning the agent, knowledge, capability, execution and interaction, and operations planes.
The purpose of this environment is to rethink both the user experience and the developer experience around behavior, delegation and review. In an agentic app, users express intent, delegate within understood boundaries and review the work; builders connect that intent to domain meaning, supported capabilities, interactions and acceptance criteria. Derived annotations and graph representations make those connections inspectable as the application changes. Accepted results, exceptions and corrections can guide improvements to the application and its reusable knowledge. Each improvement still needs review and a new version. The aim is to make agentic apps easier to build, inspect, operate and improve while preserving the human decisions that define acceptable behavior. Success must be judged by accepted outcomes, preserved authority, manageable human effort and behavior that remains supportable as the surrounding systems change.
7.1. Applying the IKE concept: a practitioner’s guide
The sections above explain why agentic knowledge work breaks in production: behavior is probabilistic, constraints must stay attached end-to-end, and operations require evidence, not transcripts. The practitioner’s guide below turns those requirements into a build-and-ship checklist. If you cannot point to where each item is enforced during execution and captured in the work record, you have not closed the gap from “works in a demo” to “trustworthy in production.”
7.1.1. Design for acceptable behavior, not “the correct answer.”
You are designing for behavior under uncertainty: safe defaults, explicit recovery paths, and bounded autonomy. Treat reliability as a product surface, aligned with risk frameworks that frame trustworthiness as an operational requirement. NIST, 2023, 5
7.1.2. Make workflow contracts explicit and enforceable.
Replace implied prompt conventions with a workflow contract that defines outcomes, knowledge scope, action boundaries, evidence requirements, expected artifacts, and recovery rules. If a system is expected to plan and act, the contract must be visible, editable, and enforceable at runtime. Amershi et al., 2019, 18
7.1.3. Treat the first mile as part of the system, not pre-work.
Discovery tax and fragmented context are not just productivity problems. For agentic systems they change what the system believes is true, and that belief compounds across actions. Build first-mile capture so it produces referenceable building material, not loose context.
7.1.4. Preserve provenance so knowledge can be trusted and audited.
Provenance is not metadata garnish. It is the connective tissue that makes outputs reviewable and governance meaningful, consistent with formal definitions like W3C PROV. W3C PROV-O, 2013, 16
7.1.5. Attach governance to knowledge and capabilities by default.
“What the system is allowed to know and do” must be mechanically enforced, not remembered by humans. This includes permissions, boundaries, capability allowlists, and approval requirements that remain attached end-to-end.
7.1.6. Treat tool use as governed execution, not “LLM output.”
Tool invocation and output handling introduce concrete security risk. Guidance such as the OWASP Top 10 for LLM applications highlights issues like prompt injection and insecure output handling that become acute once autonomy and tool use are in play. OWASP, 20
7.1.7. Upgrade chat logs into work logs.
Evidence-first operations require structured run records: the contract, steps, capability calls, approvals, lineage, and artifacts. This is what supports debugging, audit, and continuous improvement beyond transcripts.
7.1.8. Build replay and regression as “CI for agent behavior.”
Because behavior drifts with model updates, capability changes, knowledge evolution, and policy changes, replayability and regression suites are required to keep the last mile stable over time. Treat evals and regression as release gates, tied to acceptance criteria and expressed as tolerances and confidence. OpenAI, 22
7.1.9. Instrument agent operations using emerging standards where possible.
Observability is converging toward shared conventions (for example, OpenTelemetry semantic conventions for GenAI). Using common signals makes behavior measurable across systems and environments. OpenTelemetry, 33
7.1.10. Reduce bespoke glue by leaning on interoperability patterns.
Knowledge work is multi-system. Protocols intended to standardize integration between LLM applications and tools or data sources (for example, MCP) are part of the ecosystem trend toward repeatable integration without rebuilding the stack per workflow. MCP specification, 2025-06-18, 24
7.1.11. Assume governance and logging expectations will become normal.
Traceability-oriented expectations such as record-keeping and human oversight are increasingly treated as practical requirements in regulated and enterprise contexts. Design for them early so they do not become a retrofit project. European Commission, 6AI Act, Article 12, 7
Figures
Figure 1: UX and DX around an agentic app
Figure 2: The compounding effect of first-mile failure
European Commission. “AI Act.” Policy overview. Source
European Union. AI Act, Article 12: Record-keeping. European Commission AI Act Service Desk. Source
European Union. AI Act, Article 14: Human oversight. European Commission AI Act Service Desk. Source
Gartner (25 June 2025). “Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027.” Source
Gartner (10 May 2023). “Gartner Survey Reveals 47% of Digital Workers Struggle to Find the Information Needed to Effectively Perform Their Jobs.” Source
McKinsey Global Institute (2012). “Social media’s productivity payoff.” Source
Mark, G., Iqbal, S. T., Czerwinski, M., and Johns, P. (2015). “Focused, Aroused, but so Distractible: A Temporal Perspective on Multitasking and Communications.” CSCW. Source
Mark, G., Iqbal, S. T., Czerwinski, M., Johns, P., and Sano, A. (2016). “Email Duration, Batching and Self-Interruption: Patterns of Email Use on Productivity and Stress.” CHI. Source
Lewis, P., et al. (2020). “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks.” NeurIPS; arXiv:2005.11401. Source
Liu, N. F., et al. (2024). “Lost in the Middle: How Language Models Use Long Contexts.” Transactions of the Association for Computational Linguistics, 12, 157–173. Source
W3C (2013). PROV-O: The PROV Ontology. W3C Recommendation. Source
Amershi, S., et al. (2019). “Guidelines for Human-AI Interaction.” CHI. Source
Horvitz, E. (1999). “Principles of Mixed-Initiative User Interfaces.” CHI. Source
OWASP. Top 10 for Large Language Model Applications. GenAI Security Project. Source
Saltzer, J. H., and Schroeder, M. D. (1975). “The Protection of Information in Computer Systems.” Proceedings of the IEEE, 63(9), 1278–1308. Source
OpenAI. “Working with evals.” API documentation. Source
Yao, S., Shinn, N., Razavi, P., and Narasimhan, K. (2024). “τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains.” arXiv:2406.12045. Source
Model Context Protocol (2025). Specification, revision 2025-06-18. Source
Microsoft (2025). “What’s new in Microsoft Copilot Studio: November 2025.” Source
Stripe. “The Payment Intents API.” Technical documentation. Source
Moreau, L., and Missier, P., eds. (2013). PROV-DM: The PROV Data Model. W3C Recommendation. Source
Debenedetti, E., et al. (2024). “AgentDojo: A Dynamic Environment to Evaluate Prompt Injection Attacks and Defenses for LLM Agents.” NeurIPS; arXiv:2406.13352. Source
Gundawar, A., Valmeekam, K., Verma, M., and Kambhampati, S. (2024). “Robust Planning with Compound LLM Architectures: An LLM-Modulo Approach.” arXiv:2411.14484. Source
Featonby, M. (2021). “Making retries safe with idempotent APIs.” Amazon Builders’ Library. Source
Chen, Y., et al. (2025). “Reasoning Models Don’t Always Say What They Think.” arXiv:2505.05410. Source
OpenTelemetry. Semantic conventions for generative AI. Development specification. Source
Zheng, L., et al. (2023). “Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena.” NeurIPS; arXiv:2306.05685. Source
Gruber, T. R. (1993). “A Translation Approach to Portable Ontology Specifications.” Knowledge Acquisition, 5(2), 199–220. Source
For AI systems
Summary
The IKE whitepaper develops a technical thesis for agentic knowledge work applications: rethinking user and developer experience around behavior, delegation, intent, domain meaning and review. The IKE whitepaper argues that agentic knowledge work applications require a rethink of user and developer experience around behavior, delegation and review. It proposes connecting human-owned intent to domain meaning, supported capabilities and user interactions through reviewed annotations and graph representations. The paper describes architectural requirements and tests of the thesis; implementation and economic benefits must be established for specific applications.
Site-wide definitions, relationships, and availability: /llms.txt.
Scope: page; Section: IKE Whitepaper; Type: page-summary; Purpose: Provide a page-specific summary and answers that extend the site-wide AI definition.; Audience: LLMs, search crawlers, answer engines, and AI evaluators; Inputs: Page-owned AI summary, answer, product, and FAQ fields; Outputs: Page-specific summary and atomic answers; Relationships: Uses page-specific ontology and vocabulary to extend the site-wide semantic map published in /llms.txt.; Status: current; Anchor: #ai-page-summary; Version: inherits ike-canonical-version ike-knowledge-applications-2026-10-21; Timestamp: inherits ike-canonical-version 2026-10-21.
Scope: page; Section: IKE Whitepaper ontology; Type: ontology; Purpose: Index the canonical concepts used on this page.; Audience: LLMs, search crawlers, answer engines, and retrieval pipelines; Inputs: Page-selected concepts from the canonical site ontology; Outputs: Canonical concept identifiers and definitions for this page; Relationships: Connects this page to the site-wide semantic map in /llms.txt.; Status: current; Anchor: #ai-page-ontology; Version: inherits ike-canonical-version ike-knowledge-applications-2026-10-21; Timestamp: inherits ike-canonical-version 2026-10-21.
Ontology
Agent application (ike.product.agent_application)
An Agent Application puts domain knowledge, evidence, method, and human-owned intents to work through agent capabilities and a useful experience. Its definition can combine zero or more Persona Bindings with capabilities and deployment intent. Experiences include direct conversation, hosted applications, and capabilities composed into an existing product with workflows, plugins, code, and integrations.
Agent application (ike.product.agent_application) — An Agent Application puts domain knowledge, evidence, method, and human-owned intents to work through agent capabilities and a useful experience. Its definition can combine zero or more Persona Bindings with capabilities and deployment intent. Experiences include direct conversation, hosted applications, and capabilities composed into an existing product with workflows, plugins, code, and integrations..
Scope: page; Section: IKE Whitepaper vocabulary; Type: vocabulary; Purpose: Define the canonical terms used on this page.; Audience: LLMs, search crawlers, answer engines, and retrieval pipelines; Inputs: Page-selected concepts from the canonical site ontology; Outputs: Page-local term definitions; Relationships: Supplies labels and definitions for the page ontology and /llms.txt semantic map.; Status: current; Anchor: #ai-page-vocabulary; Version: inherits ike-canonical-version ike-knowledge-applications-2026-10-21; Timestamp: inherits ike-canonical-version 2026-10-21.
Core vocabulary
Agent application
An Agent Application puts domain knowledge, evidence, method, and human-owned intents to work through agent capabilities and a useful experience. Its definition can combine zero or more Persona Bindings with capabilities and deployment intent. Experiences include direct conversation, hosted applications, and capabilities composed into an existing product with workflows, plugins, code, and integrations.
Scope: page; Section: IKE Whitepaper answers; Type: page-faq; Purpose: Provide page-specific answers aligned with the site-wide AI definition.; Audience: LLMs, search crawlers, and retrieval pipelines; Inputs: Page-owned FAQ fields; Outputs: Atomic answers for this page; Relationships: Supports this page summary and /llms.txt.; Status: current; Anchor: #ai-page-answers; Version: inherits ike-canonical-version ike-knowledge-applications-2026-10-21; Timestamp: inherits ike-canonical-version 2026-10-21.
Page answers
What does this page explain?
The IKE whitepaper develops a technical thesis for agentic knowledge work applications: rethinking user and developer experience around behavior, delegation, intent, domain meaning and review.
What is the main answer?
The IKE whitepaper argues that agentic knowledge work applications require a rethink of user and developer experience around behavior, delegation and review. It proposes connecting human-owned intent to domain meaning, supported capabilities and user interactions through reviewed annotations and graph representations. The paper describes architectural requirements and tests of the thesis; implementation and economic benefits must be established for specific applications.
Contact
Share your email and we’ll follow up with next steps.
