Agentic Apps
Agentic Apps let an agent work inside a running app. The agent reads the current screen, acts on it, and checks that the result was applied. A user describes their intent via prompt, and the agent finds the right app, opens the right page, fills the fields, and verifies the outcome.
Agentic Apps works with App Designer apps, Adaptive Designer apps, and UI5 apps, including SAP screen components and the Neptune Bootstrap components. It is available by default for App Designer and Adaptive Designer apps. You can turn it off for an app in its application settings. When the setting is turned off, the agent cannot interact with that app.
| For a step-by-step walkthrough that sets this up end to end, see Set up Agentic Apps. |
Prerequisites
To use Agentic Apps, you need an agent that has Agentic Apps turned on, made available where the app runs:
-
Turn on Enable use with Agentic Apps for the agent. See Enable use with Agentic Apps. The agent uses the model configured for it.
-
Provide the agent where the app runs:
-
In a launchpad, on the Agent tab, select an agent in the AI Agent field. This agent powers the chat panel and can be a normal agent or an Agentic Apps agent. If the field is empty, no chat panel appears. Then, in the Agentic Apps section, select the Agentic Apps Agent that operates the apps. See Agentic Apps in a launchpad.
-
In a standalone app, add a Chatbox with an agent assigned, and turn on Agentic Apps in the app’s Application Settings.
-
How Agentic Apps work
On each turn, the agent works against the live screen in three steps:
This involves the following turn of actions:
- Read the screen
-
The agent reads the current state of the app, including the components on the page and any open dialogs.
- Act
-
The agent operates the app with built-in tools that cover the supported screen components, and with any custom tools the app registers.
- Verify
-
The agent checks that its action took effect before it continues or reports that the task is done.
The agent carries out a multi-step request in order. When a step depends on an earlier one, it acts on the updated screen rather than an assumed result. It stops when the task is complete or when it cannot make further progress, and reports what it did. It does not report success when an action did not take effect. For a long sequence of steps, the agent can stop before finishing, continue with a follow-up message, or split the request into smaller ones.
In a launchpad, the agent chooses which app to open by matching the request against each app’s description, so a clear app description is what routes a request to the right app.
Working with Agentic Apps
A user works with the agent through the chat, and does not have to know which app to use or where each field is:
- Describe a task in plain language
-
Describe what action you want to achieve, with the details that matter, for example a leave request for a set of dates. The agent fills the request in the app. If you ask it to submit, it submits. If the app requires a review first, the agent stops and waits for your confirmation.
- Complete a multi-step task
-
Describe a task that takes several steps, for example, fill a form and then submit it. The agent carries out the steps in order and checks each one before it continues.
- Provide a file as input
-
Upload a file into the chat, for example an invoice, and describe the task, for example an expense claim. The agent reads the file, opens the right app, and fills the form from the file.
- Ask about the current screen
-
Ask the agent a question about the app you are on, for example, what you can do on a certain screen or what a field is for. The agent answers about the current screen and does not change anything.
The agent keeps the context of the conversation and the app, so you can refine with a follow-up message. When it fills a field you did not state, it explains why. It can also ask for a missing detail, or fill it from the context the app provides.
To make the agent act accurately in a specific app, a developer describes the app and, where needed, gives it custom tools and a list of components to leave alone.
Describe an app with AGENTS.md files
The agent identifies controls from what is on the screen: a field’s label, including
a label linked by an ARIA association, and a column’s header. AGENTS.md files
are supplementary — they add context the screen does not show, and are not needed
for the agent to read labelled controls.
An AGENTS.md file gives the agent context about an app in plain language: what the
app is for and when to use it, what specific fields, buttons, drop-down lists, and
filters do, and the business context behind them, such as how to classify a product
or which cost center applies.
-
The file must be named
AGENTS.md. -
AGENTS.mdfiles are additive. The agent operates the app without them, and each file you add gives it more context. -
Each
AGENTS.mdfile registers its path when the app is built. When the agent runs, it reads where the user is in the app and receives the files relevant to that path. Place a file next to the part of the app it describes, and add as many as you need.
This is the same behavior as AGENTS.md files in other tools: context is scoped by
location, so the agent gets the guidance that applies where it is working. Add
AGENTS.md files as Markdown resources in the
application tree.
Use AGENTS.md to shape how the agent behaves, not only to describe the app. For
example, instruct the agent not to guess and to ask for any detail it does not have,
so it stops and asks instead of filling in a value itself.
Keep the guidance concise and specific, and write it as instructions to follow. Prefer a scoped file placed next to the relevant part of the app over one large app-level file: a scoped file reaches the agent only when its part of the app is on screen, so guidance stays relevant and does not apply where it should not.
To require a review before the agent submits, add a stop point, for example: "Before pressing Submit, summarize the request and wait for the user to confirm".
Register custom tools
Built-in tools let the agent read and operate the supported screen components. Register custom tools when the agent needs to do something the screen cannot express on its own, such as querying or filtering data on the server and returning an exact result.
Define custom tools in a JavaScript resource
of the app with neptune.ia.registerTools. Pass the local view ID and a function
that returns the tools. The agent calls this function every time it requests
tools, so you can return different tools depending on the current state, which the
function receives as snapshot.
neptune.ia?.registerTools(localViewID, ({ snapshot }) => {
const tools = [
{
name: "refreshOrders",
description: "Reload the orders list from the server. Call after creating or changing an order, or when the list looks stale.",
parameters: [{ name: "region", type: "string", required: false }],
execute: async (args) => {
const region = typeof args.region === "string" ? args.region : undefined;
const result = await reloadOrders(region);
if (!result.ok) {
return { toolId: "refreshOrders", success: false, message: result.error };
}
return { toolId: "refreshOrders", success: true, message: `loaded ${result.count} orders` };
},
},
];
const approvalOpen = snapshot?.openPopups?.some((p) => p.id.endsWith("approvalDialog"));
if (!approvalOpen) {
return tools;
}
return [...tools, {
name: "submitApproval",
description: "Submit the currently open approval dialog.",
execute: async () => {
const result = await submitApproval();
return { toolId: "submitApproval", success: result.ok };
},
}];
});Each tool has a name, a description that tells the agent when to call it, an
optional list of parameters, and an execute function that does the work and
returns the result. In the example, the submitApproval tool is offered only while
the approval dialog is open, because the function reads snapshot each time the
agent requests tools.
Custom tools are also registered with WebMCP when WebMCP is turned on for the app.
Exclude components from the agent
To stop the agent from interacting with a component, add the component to the denylist, so the user handles that component. Configure the denylist on the Agentic Apps tab of the app’s application settings.
Use the denylist for a specific control the agent must not use. To steer the
agent away from a whole area, a scoped AGENTS.md next to that area is often better
than denying a container: denying a container, such as a layout that holds several
inputs, also removes the interactive controls inside it that the user still needs.
|
WebMCP
WebMCP exposes an app’s Agentic Apps tools, including custom tools, over the Model Context Protocol, so an external agent can drive the app with the same tools.
With WebMCP, the external agent is one the user brings. Its activity does not run through the agent configured in Naia Agent Studio, so it is not subject to that agent’s guardrails or audit. The built-in Agentic Apps path uses the configured agent instead, and follows the guardrails and logging set up for it.
| WebMCP for Agentic Apps is available as a beta feature. As the tool continues to develop, you may notice updates and improvements over time. |
When you turn on WebMCP for a launchpad, the launchpad itself exposes no tools. The tools become available once the user opens an app inside the launchpad. For an app that runs inside a launchpad, the launchpad WebMCP setting takes precedence over the app’s own setting.
Built-in tools
The agent operates the supported screen components with built-in tools, which cover the SAP screen components and the Neptune Bootstrap components.
Considerations
-
The agent works on the app that is open in the browser. It acts on the current screen and the pages the user can reach in the app.
-
The agent works best when the app is described well. Meaningful app descriptions and
AGENTS.mdguidance improve how reliably it finds the right app and fills the right fields. -
The agent uses the model configured for it. The choice of model affects how well it follows instructions, how it selects actions, and how long a task takes.
-
You can trace and debug an Agentic Apps agent in the Agent Trace tool, like any other agent.
-
WebMCP is experimental and must not be relied on as a production feature.