Most AI projects don’t get much further than a chatbot window and a prompt. A person asks for something, the model answers, and someone copies the useful parts into another system, maybe asks a few more questions, and then closes and loses the chat session. Weak. How do we make a user’s life better? We build agentic applications around what they already do regularly, making that work easier with agentic support, source data, permissions, business rules, and an interface people depend on.
IKE helps in two connected ways. Builder turns the team’s description of a repeated workflow and the product’s own rules into a working application. After the team accepts a version, the IKE control plane publishes it, supplies the runtime, and keeps its Persona, knowledge, tools, permissions, sessions, and lineage connected. People see a workflow that matches the job. IKE records each run so the team can inspect what happened and improve the next version.
For an existing product, this means making a real workflow inside it agentic. The product contributes its domain meaning, records, screens, valid actions, and operating rules. IKE provides the application construction and operating environment around those things.
The lifecycle diagram above follows that progression from Builder to an accepted application, runtime, and improvement. The AML example below walks through it using one request: “Brief me on today’s work.”
This foundation stays connected while the briefing runs. A Persona establishes how the agent should operate for the role, and reviewed Knowledge supplies context for interpreting the work. Skills and Tools provide capabilities, Permissions constrain their use, and Lineage records the sources and actions behind the result.
See the first iteration around an established AML product
We are working with a design partner that has an established anti-money laundering (AML) product. The partnership is building an agentic offering around that product to extend and improve the experience its customers already use. The first working iteration came together quickly and shows what IKE can add around an existing product. We have omitted the company and product names from this public description.
That iteration focused on a workflow in which relationship managers need to understand the cases assigned to them before they contact a client. Compliance officers need the same underlying evidence, viewed through a different role and set of responsibilities.
The example begins with a small but useful slice: brief a relationship manager on today’s assigned cases, explain which items need attention, and provide actions that open the correct case. Even this small slice has to handle project-specific terms, current business records, role-based access, model judgment, predictable navigation, and a screen inside the existing workbench.
A relationship manager opens an agent panel inside the AML product and asks, “Brief me on today’s work.” Producing a useful result requires the application to decide whose cases count as “my work,” which evidence makes a case urgent, what the user may see, and where the briefing should appear. An action on the resulting card must also carry the correct case identity into the next screen.
Start with the behavior people expect
The application’s intent includes a scenario called “Brief me in the Agent panel.” It describes a briefing shaped by the user’s role, supported by current work, and presented as one case-summary card with useful next actions.
The human-maintained source states that behavior in Gherkin before Builder connects it to implementation details:
Scenario: Brief me in the Agent panel
Given my current work has been gathered
When the Agent panel prepares my briefing
Then summarize the complete role-scoped work set in business terms
And rank the most useful priorities for my role
And suggest only next actions supported by the current work and my permissions
And render one case-summary card with a greeting header, ranked priorities, and supported next actions
The requirement is specific enough to review. “My work” means cases assigned to the user’s current product identity, which the application connects to its selected Persona Binding. Priority follows the AML team’s rules and the evidence available for that case. Application roles and policies determine which cases the user may see. Read and navigation actions can open or focus a case. A suggested business change begins as a proposal for human approval.
The same requirement can produce different results for a relationship manager and a compliance officer. Their responsibilities differ, as does the work in front of them. The application preserves the method while applying it to the current role and situation.
To turn that behavior into an application, Builder needs reviewed meanings for the terms in the requirement, an understanding of the product behavior available to it, and mappings to the systems that provide facts and operations. “My work” and “urgent” must resolve to definitions the product team has agreed on.
Builder will Resolve the requirement against this foundation, Annotate it with application details, Materialize the workflow, and use Skeptic to check it against the original intent. First, the team prepares the knowledge those phases will use.
Prepare the knowledge environment before Resolve
Before Builder resolves a scenario, the team prepares a knowledge environment: a reviewed account of the domain, the product, and the systems the application can use.
Locus (being rebranded as IKE Lens) is where that capture begins. The source material includes pages, documents, requirements, descriptions of connected systems, and the existing product experience. The preparation work draws out the vocabulary, relationships, expected behavior, available operations, and open questions.
A product owner and subject-matter expert review the proposed knowledge. They agree on terms, resolve ambiguity, and confirm the sources and policies that apply. IKE keeps accepted knowledge as versioned Knowledge Artifacts in Collections, with human-readable material available for review.
That review produces reusable knowledge structures. An ontology gives concepts consistent names and relationships. The product map connects expected behavior to the screens and actions the product supplies. Source mappings connect those concepts to the systems that hold the facts. Search and graph indexes make the accepted material available to Builder while retaining its source and version.
For “my urgent cases,” this preparation establishes what each part means: “my” follows product identity and access rules, while “urgent” follows agreed policy and evidence. Resolve uses the relevant reviewed knowledge to connect those meanings to the right sources, allowed tools, and result screen.
Keep each map with its owner
The application brings together several views, each with its own owner. The first three prepare Builder’s inputs. Builder then produces the workflow from the reviewed intent and those inputs.
| View | What it records | Example from AML |
|---|---|---|
| Domain meaning | Terms, relationships, and policy meaning. | What a case or piece of evidence means and how priority is interpreted. |
| Product intent and behavior | Valid screens, actions, components, and user outcomes. | The Agent panel, case-summary card, navigation action, and approval boundary. |
| Source connections and tools | Where facts live and which operations the application may use. | Assigned cases, supporting evidence, and the tools that read them. |
| Workflow produced by Builder | The work to perform, its dependencies, and the expected result. | Gather assigned work and its evidence, then prepare the briefing. |
For the “case-summary card,” domain knowledge explains what the summary means, the product supplies the panel and valid actions, and Builder connects the requirement to the evidence and preceding work. Each action retains its case identity when it opens the destination screen. Keeping these details with their owners lets the team change a business term, source connection, or screen in the right place.
Show what the AML product owns and what IKE handles
For “Brief me on today’s work,” the product supplies the business meaning and the IKE control plane operates the application around it. Their responsibilities meet at each step:
| Step | The AML application supplies | IKE Builder and control plane supply |
|---|---|---|
| Open the work | User roles, identity mapping, source connections, case screens, and valid actions. | Control plane hosting, launch, Persona Bindings, and sessions. |
| Prepare the briefing | What assignments, evidence, priorities, and case summaries mean. | Builder workflow, allowed context, step order, and model or tool work. |
| Inspect or act | The exact case, allowed business actions, approval rules, and destination screen. | Control plane access checks, tool calls, result handling, and hosted UI. |
Store knowledge with its identity intact
For the AML briefing, a policy’s owner, source, version, and period of applicability matter as much as its wording. The team needs to know which reviewed meaning of “urgent” the application used.
IKE keeps the accepted Knowledge Artifact and its source identity. Document or vector indexes support search; graph indexes keep the facts and relationships from each document. These indexes can be rebuilt from the source, and each retrieved match remains traceable to the material it represents.
That prepares a reusable account of the domain and product. When the application runs, it also needs the actual work in front of the current user.
Connect the workflow to live systems
The knowledge and product graphs describe the systems an application can use, what their records mean, and which integrations and tools provide access. They give Builder the knowledge needed to connect the workflow to those systems. The integrations supply current data and carry out permitted operations when the workflow runs.
When the relationship manager asks, “Brief me on today’s work,” the accepted workflow uses those integrations to find their assigned cases and retrieve current evidence. It uses the product’s navigation action to open the right case screen. The records remain owned by the AML source system, and the user’s permissions and product rules apply throughout the run.
The runtime diagram follows this use: the application combines its reviewed understanding with current records for this user. The application’s source and access rules determine which retrieved material and tools it may use.
A model’s explanation is a new result supported by those records and the reviewed knowledge. Making it reusable knowledge requires a deliberate save or review under the application’s rules.
Build with IKE. Run on the IKE control plane
Builder now has the inputs assembled above: human-written intent, reviewed domain meaning, the product experience, source mappings, available capabilities, and applicable controls. Before runtime, it connects those pieces into an application workflow the team can review and accept. The control plane publishes that accepted version, supplies the runtime, and records what happens when people use it.
The flow moves through Builder’s four phases, then publication, operation, and improvement:
- Resolve connects the requirement to reviewed meaning, product behavior, source mappings, and permitted tools.
- Annotate links the scenario to concrete application details: source mappings, tools, screens, and rules.
- Materialize builds the workflow, including the work each step depends on and the result it should produce.
- Skeptic looks for gaps between the workflow and the original intent.
- Publish gives the control plane an accepted application version, along with its access, hosting, and configuration.
- Run executes that version with the current user, permissions, records, applicable models, APIs, and tools for each request.
- Observe and improve records sources, actions, lineage, and run state. Reviewed findings become inputs to the next Builder version.
For the briefing, the prepared workflow connects gathering the user’s assigned work, obtaining the evidence, and presenting a useful summary. The team tests and accepts a version before putting it into use. Each request runs that workflow with the current user and records, so the briefing reflects the work in front of that person.
Use model judgment where it helps the work. Keep deterministic product behavior in application code. Interpreting incomplete evidence or explaining a case may require a model. Checking permission, calling a known API, validating its response, rendering a registered screen component, and navigating to the correct case belong in application code.
Tests need to cover both. A valid workflow can still produce a poor explanation. A strong model score does not tell you whether the right card appeared or whether its action opened the right case.
Follow the chain back from the screen
To inspect why a briefing ranked a case first, the team needs to connect what appeared on screen to how the application was built and what happened in that run. The AML workflow keeps the briefing requirement, its annotations, business meaning, application details, and saved workflow in separate records that can be reviewed together. Lineage and run history connect the result to the sources and actions used during execution.
The saved artifacts show how the application was prepared. A live demonstration proves what a particular application build, knowledge version, and runtime configuration actually do. A release needs both kinds of evidence.
Apply the pattern to your project
The result in AML is a role-specific briefing inside the real product, backed by current evidence and actions that retain the correct case identity. The product continues to own its domain, records, policies, actions, and interface. IKE turns that repeated work into an Agent Application, runs the accepted version with the current user and evidence, and preserves lineage for inspection and improvement.
The same method applies to another product or internal workbench: start with its domain vocabulary, source integrations, screens, and operating method. If the work still lives in documents and meetings, start with one request a skilled person answers again and again. Identify who asks, what counts as their work, which evidence they need, what they may do, and where the result belongs.
The Agent Application model explains the wider architecture. A Design Partnership starts with one end-to-end path through your own workflow.
