The Organizational Context and Harness for Building Agentic Capabilities in SaaS Products

Overview

Most enterprise applications were built for people to operate through screens, APIs, and established workflows. Their capabilities are spread across user interfaces, services, data stores, access policies, and undocumented dependencies. An AI agent cannot reliably act on a product simply because it can read some code or call a single API. It needs to understand what the product can do, what information each task requires, how outcomes are expressed, and where people must remain in control.

Context Engine & Agentic Harness explained here builds agentic capabilities on top of existing UI and backend applications. The context engine gives agents a connected, executable understanding of product capabilities: interface actions, backend operations, data and conditions that shape their behavior, and outcomes that indicate success. Agents use that understanding to carry out business workflows through the applications people already use.

The primary use case is enabling customers to ask an agent to complete a business workflow. The agent identifies the appropriate flow, gathers required information, operates the relevant UI or backend capabilities, and returns the outcome. Existing application behavior and authorization controls remain part of execution, with user approval at consequential actions.

AI-assisted development is another use case built on the same foundation: agents use product flows and acceptance criteria to help developers implement and verify changes. The same capabilities could also support product-incident investigation and resolution. Embedding context engine throughout the SDLC could give product, engineering, QA, and support teams a shared understanding of product workflows and their data interfaces, helping them coordinate and orchestrate those workflows more effectively.

The work described here demonstrates an implemented approach exercised in a controlled production-like environment. It does not include quantified before-and-after results for cost, delivery time, defects, or onboarding. Benefits described below are objectives and hypotheses to evaluate, not measured claims.

The problem: capable applications are difficult for agents to operate

An application may expose useful functionality through a UI, REST or GraphQL APIs, gRPC services, and database operations. A single user goal can cross several boundaries. A UI field may have validations and state-dependent behavior, call a backend service, and rely on a particular database record. Feature flags may change behavior by environment. The knowledge needed to complete the task is distributed across code, data, configuration, and people.

Giving an agent access to one interface does not give it this full picture. Without connected context, an agent may not know which operation matches the user's intent, what inputs are valid, which downstream behavior to expect, or when a human must approve an action. Teams often build one-off integrations and prompts for each agent and workflow, which can be difficult to reuse as applications change.

The challenge is to make product capabilities available to agents in a form that connects intent, behavior, required data, execution, and outcom while preserving the controls of the systems being operated and letting people inspect and correct what the agent understands.

The perspective shift

Context engine starts from capabilities that already exist. It aims to make them agent-operable through an explicit model of flows and executable units, rather than treating AI as a separate layer with ad hoc knowledge of the product.

• From isolated interfaces to connected capabilities. UI actions, backend operations, data sources, and expected outcomes are understood as parts of product behavior.
• From one-off agent context to reusable product knowledge. A flow and its data requirements can be reused by different agents and clients.
• From AI that only recommends to AI that can operate. An agent can invoke a flow, observe its result, and report what happened, subject to system permissions and human approvals.
• From automation without context to behavior-grounded action. The agent selects documented flows and data variants, then checks observed responses against expected behavior.
• From documentation as a handoff artifact to documentation as an operating model. The specification supports exploration and execution as well as communication among product, engineering, QA, support, and AI agents.

This approach does not require replacing the existing UI or backend. It seeks to expose their capabilities in a consistent, navigable way so agents can use the systems through their established interfaces.

What agentic application capability means here

Context engine represents an application as connected flows and executable units. A flow describes a user or business journey. Its steps may involve UI elements and actions, backend APIs or other protocols, and data needed to produce particular behavior. Individual UI and backend units can also be explored or invoked apart from a larger journey.

The model connects the task an agent is asked to perform; available flows; actions and validations; data identifiers and variants; dependencies between UI, services, and databases; expected behavior and observable results; and the approvals and access boundaries for execution.

The current specification is stored in YAML. Users can inspect and correct generated flows, vocabulary, and data variants in context engine. If the crawler misses a task, flow, or data variant, users add or correct that definition in the context engine UI. Chat and the target applications are not authoring surfaces for these definitions. Graph storage such as Neo4j is a possible future direction; YAML is the current representation.

A perspective on use cases

Agents executing business workflows

Users select from the discovered flows and predefined flow instances available in context engine. They may also ask the chat agent to run an available flow; the agent resolves the request against that existing catalog. Chat in production application does not create or define flows, tasks, or data variants. The agent determines the selected flow's required inputs and invokes the corresponding application capabilities. UI flows can run through browser automation or inline UI manipulation in the target application. Backend units run through context engine APIs and MCP tools. The caller receives results from the application being operated.

For UI execution, the flow pauses at submit actions and application confirmation points so the user can review, modify, and approve before proceeding. For backend API execution, validation occurs and the request is sent only after user acceptance. The AI account uses the destination UI, backend, and database authorization policies. context engine does not currently centralize authorization across those systems.

AI-assisted development with BDD and TDD

This use case applies behavior-driven development (BDD) and test-driven development (TDD) to agent-assisted software delivery. Product and engineering teams define task-level UAT acceptance criteria as observable behaviors. The context engine AI connects those criteria to the relevant UI and backend flows, data identifiers, and variants in the YAML specification, working with the developer to fill in or correct the generated context.

BDD provides a shared description of what the product should do from the user's perspective. Each acceptance behavior maps to an executable flow and selected data variants. The agent runs that flow through the UI or backend and compares observed results with the expected behavior, giving product, development, and QA a common scenario and outcome to review.

TDD brings those executable checks into the developer's implementation loop. The developer defines or selects the relevant behavior checks before or alongside the code change, runs them to see which expectations are not yet met, implements the change, and reruns the checks. Unit tests can cover individual code units, while the connected flows verify behavior across UI elements, services, and data. If a run fails, the IDE agent examines the failure, acceptance criteria, and code, then suggests a correction. After the developer approves, the agent can apply the change and rerun the checks.

The same capability supports connected-component testing: a change to one component can lead to tests of related flows and components. DevOps teams can invoke context engine through their CI/CD system using its APIs or MCP tools. Runs can occur on pull request commits, after merge, and in different environments where feature flags may change behavior. CI results link to reports in context engine, where users can revisit runs by timestamp, flow, variants, environment, and observed actions.

This development and testing workflow is one application of the broader agentic capability model, not its boundary.

Production Support

A secure sandbox can give agents controlled access to indexed codebases, the context engine, data tools, and MCP-enabled observability and monitoring systems. Agents can use these tools to perform an initial analysis of alerts and incidents while masking personally identifiable information (PII) and sensitive customer data. They can then present their findings and recommended next steps for users to review in real time, helping teams resolve issues faster.

The approach and experiment

Context engine applies this approach by connecting repository analysis, product behavior, data, and execution:

1. Understand the system. Organizational repositories are indexed through any AST Parsing libraries, with code structure and abstract syntax trees available for analysis. The system identifies executable units across UI applications, backend services, protocols, and database operations.
2. Trace behavior. Analysis follows UI elements and validations through service calls toward the data sources and conditions that determine behavior.
3. Derive variants and flows. Data variants are associated with behaviors, and flows connect relevant elements, operations, data, and expected outcomes. People can review and correct generated understanding in context engine.
4. Expose capabilities to agents. Flows and individual units are available through the context engine UI, chat, APIs, and MCP tools, including from compatible clients such as IDEs.
5. Run with controls. The agent obtains or requests required data, invokes UI or backend behavior, pauses for approval where required, and returns the observed result.

The implementation is intended to orchestrate different UI technologies and backend communication protocols. Practical coverage depends on whether a system can be analyzed and its capabilities invoked with appropriate access. This also calls for agentic coding practices: structuring code and service abstractions so agents, as well as people, can read, understand, and operate them.

Terminology used in the experiment

The crawler represents discovered application structure and behavior using these concepts:

• Component A UI component discovered while crawling the application. Components can be standalone or nested within other components.
• Element An interactive control within a component, such as a text field, checkbox, or dropdown.
• Data identifier A named input used by an element or flow, together with its data type and possible values. For example, a checkbox may take a Boolean value; a multi-select may take a list; and a dropdown may use predefined options or options fetched from an external service.
• Data variant A named value or data condition for a data identifier that exercises a particular behavior. For an Account object, account_number might have variants such as active_account_number, inactive_account_number, and dormant_account_number. The selected variant determines the data supplied and can lead to different application behavior.
• Flow A reusable sequence of UI actions and elements that represents a user journey. A flow can span one or more components and refers to data identifiers without fixing their variants.
• Flow instance A named scenario based on a flow with specific data variants selected. For example, order_creation_blocked_for_inactive_account_number could be an instance of an order-creation flow with inactive_account_number fixed for that run.
• Action An operation performed on an element, such as clicking, hovering, dragging, or entering a value.
• Behavior An observable, verifiable outcome caused by an action. The outcome may appear on the current element or on a later element in the flow.
• Integration An external connection used by an element or flow, invoked automatically or in response to a user action, such as a call to a service or another system.

A context engine spec model could look like,

OrderComponent:
    description: Component used to create order
    elements:
        account_number_input_field:
            actions:
                fill:
                    value: account_number
                        behaviours:
                            valid_account_number: 
                                OrderComponent.message: order successful
                            inactive_account_number:
                                OrderComponent.message: order failed
                            dormant_account_number: 
                                OrderComponent.message: order failed
        product_select_drop_down:
            actions:
                select:
                    value: product
                        variants:
                            product_one
                            product_two
                            product_three
            integration:
                rest:
                    method: post
                    url: /products
                    service: product-service
                    headers:
                    request_body:
        quantity_input_field:
            actions:
                input:
                    value: any number
        order_submit_button:
            actions:
                click:
                    integration:
                     rest:
                        method: post
                        url: /products
                        service: product-service
                        headers:
                        request_body:
        message: 
            text:

flows:
    create-order:
        description: flow used to create orders
        sequence:
            - account_number_input_field
            - product_select_drop_down
            - quantity_input_field
            - order_submit_button
            - message 
    
flow-instances:
    order_creation_blocked_for_inactive_account_number:
        descriptions:
        sequence:
            - account_number_input_field [inactive_account_number]
            - product_select_drop_down [any]
            - quantity_input_field [any]
            - order_submit_button
            - message [order failed]

For backend specifications, it will have the data identifier, data variants and its behaviors alone in the spec file.

A reusable flow lets the user select data variants; a named flow instance can have variants fixed in advance. For example, an account-number field might use active, dormant, inactive, or invalid account variants. The chosen variant is supplied to the appropriate element, and its resulting behavior may appear later in the journey.

Context engine distinguishes two kinds of data:

• Systemic data comes from an actual database or system.
• Synthetic data is generated to mimic data and does not come from an actual in house system.

When data can be derived from code and available systems, context engine can associate a variant with an MCP tool that retrieves a suitable value. If data cannot be derived or is unavailable, a person can provide it for the run. In production, the agent does not invent synthetic values: it requests the exact required data from the user.

What has been demonstrated

The implemented approach connects application flows to UI behavior, backend operations, and data variants. As its primary capability, an agent can map a user's request to an available business flow, obtain the required data, and operate through the corresponding UI or backend units with the described approvals. Users can also explore flows and individual executable units, select variants, review previous runs, correct generated flows, and define custom flows in the context engine UI for reuse.

A chat-based agent workflow has been exercised in a controlled production-like environment. This experiment was not run against a live production system. AI-assisted development and testing uses the same connected flow model as a further application of the capability.

These demonstrations show a way to make existing application capabilities available to an agent through connected context and executable flows. They do not establish that every application can be fully reverse-engineered, that every task can be safely automated, or that context engine has already reduced delivery cost or effort by a measured amount.

Intended impact and evaluation

The intended impact is to let product users complete business workflows through agents, while reducing the effort needed to connect those agents to application capabilities. Reusable flows may reduce one-off integration work and repeated discovery of cross-system behavior. The same foundation may also reduce manual test setup and help teams apply agent capabilities to more tasks without rebuilding product context each time.

These remain hypotheses. context engine has no measured before-and-after observations for time saved, cost, defects, coverage, or onboarding. Evaluation should establish baselines and compare similar work after adoption, including:

• business workflow completion rate and time from user request to verified outcome;
• human approval, clarification, and intervention rates during workflow execution;
• time and effort to configure an agent for an application task;
• time spent tracing dependencies and preparing usable data;
• one-off integrations or prompts replaced by reusable flows;
• failures caused by missing context, incorrect action, or unavailable data;
• human approval and intervention rates;
• onboarding time and the number of systems a person or agent must inspect;
• operational cost of maintaining flows and running agent executions.

Evaluation should distinguish tasks that are successfully automated from those that still require human investigation or direct operation.

Conditions and limitations

Agentic behavior depends on the quality of system understanding. Clear, structured code is easier to analyze deterministically. Legacy systems with tangled or implicit behavior may require human review and correction. Context engine surfaces incomplete flows and data so people can improve the model over time.

Some data cannot be logically derived or fabricated, and required records may not exist in an accessible database. In those cases, a person must supply data for each run. A flow without suitable data cannot be assumed fully executable.

Execution depends on destination application availability and permissions. The destination application controls the AI account through its own authorization policies; context engine does not impose one centralized authorization layer. The production-like experiment does not establish the safety or effectiveness of unrestricted live production operation.

Agent-operable systems also need code and interfaces that are understandable to people and machines. Maintainability, clear domain concepts, suitable design patterns, and practices such as SOLID remain important. Teams must make behavior and dependencies explicit enough to analyze, document, and connect to user intent.

Conclusion

Context engine explores a general path for building agentic capabilities on top of existing UI and backend applications. Agents need more than a model and a tool call: they need a connected understanding of what the application can do, what data drives its behavior, how outcomes can be observed, and where human control applies.

The primary opportunity is to let product users delegate business workflows to agents operating through existing products, with those products' capabilities and controls as the operating surface. AI-assisted development and testing demonstrates an additional use of that foundation. Whether this approach reduces cost, effort, or time remains to be measured across real tasks and applications.