Agent tooling
On CAP Node.js the agent is a service. @agent on a service definition serves it over A2A, the service's own entities and actions are its tools, and the files beside the service definition — AGENTS.md and skills/*/SKILL.md — are where its identity and its workflows are written, instead of handlers.
Showing artifacts, examples and content with confirmed Node.js applicability. View All CAP
Overview
@cap-js/agents@cap-js/agentsSAP's own CDS plugin for building agents inside a CAP service, wired to audit logging and telemetry through peer dependencies rather than leaving observability to the author.sap official, cap is the whole answer here: @agent on a service definition serves the agent over A2A with the service's own entities and actions as MCP tools, @agent.hitl pauses an action until a person approves it, short-term memory sits in the connected primary database, quotas are enforced per tenant and per user, and audit events and OpenTelemetry metrics are emitted when @cap-js/audit-logging@cap-js/audit-loggingIntegration with the SAP Audit Log service, so operations on personal data are recorded in the form an auditor expects without the application writing the entries.sap official, cap and @cap-js/telemetry@cap-js/telemetryAutomatic OpenTelemetry instrumentation for CAP Node.js services and their database calls, exported as traces and metrics to the console, SAP Cloud Logging, Dynatrace, Jaeger or an OTLP endpoint.sap official, cap are installed. In the development profile the plugin reads model credentials from a local Claude Code or OpenCode installation, so a first run needs no configuration.
Not covered: At the generic index.html chat preview, which capire marks experimental and for local development, and at the plugin's own harness: the features capire lists as still to come include agent memory across sessions, alternative harnesses, custom-coded agents, evals-based testing and file I/O.
@mi8y/cds-langgraph-persistence@mi8y/cds-langgraph-persistenceA LangGraph checkpointer backed by CDS, so an agent's state survives the request that created it — durability for LangChain and LangGraph agents running inside the CAP Node.js runtime.independent, cap and @mi8y/cap-agents-memory@mi8y/cap-agents-memoryA LangGraph Store written against CDS: the facts and preferences an agent keeps between sessions are entities in the CAP database, read and written inside a request handler under its tenant.independent, cap carry LangGraph's own state inside CDS, one thread at a time and across threads, cds-agentscds-agentsTurns a CAP service into a tool layer for agent frameworks — a CAPToolkit bound to a named service, with a tool strategy controlling how much of it becomes callable.independent, cap hands a running service to LangChain or LangGraph as tools from outside it, and cap-agent-ui5-webuicap-agent-ui5-webuiGives a CAP agent a UI5 web interface out of the box, so an agent built in the service has somewhere to be talked to without a separate frontend project.independent, cap serves a UI5 chat client against the A2A endpoints.
Policy
PolicySAP API Policy 4.2026a§ 2.2.2AlwaysAn agent built into an application reaches SAP Application APIs, whether directly or through tools generated from a service that proxies them.
- § 2.2.2 AI call sequences and data extraction. Outside SAP-endorsed architectures, data services or expressly identified pathways, the policy prohibits specified agentic API use and systematic or large-scale extraction.
capire's own guide states that CAP-level agents are intended only for exposing custom CAP application services, and names section 2.2.2 for the agentic-access provisions. Check which endpoints the agent's tools end up calling, and consult SAP's reference architectures for the endorsed routes.
SAP API Policy 4.2026a →Artifacts
Tasks
Answer a user's question inside the application
Someone using the application asks in plain words and the application answers from its own services, with the agent running inside the deployed application rather than in the asker's own AI client.
Covers the agent that runs in the application, the tools it gets from the service and the endpoint it is reached at. Reaching a model is LLM integration, exposing the same service to somebody else's agent is MCP servers, who may read a row is authorization, and the screen the conversation happens on is assessed on its own. Which entitlements a subaccount holds is a project question and is not assessed here.
@cap-js/agents@agent on the service definition is the whole setup: the plugin generates MCP tools from that service's entities and actions, runs a ReAct loop over them and serves the result over A2A. capire's own walk shows the two halves of this outcome — asked to list books the agent calls the generated describe and query tools, and asked to order one it calls the service's action through the call tool. An AGENTS.md next to the service definition replaces the generated agent with one built from the directory, which is the route to take when the answer has to follow written instructions rather than whatever the model infers from the model.
Remaining work: Decide which service the agent is put on and what its projection exposes, since the tools come from that model. Configure a model: the development profile reads credentials from a local Claude Code or OpenCode installation, and production and hybrid use the aicore kind against SAP AI Core. Where the answer has to be deterministic, the AGENTS.md and the skill files are the project's to write.
cds-agentsComes at the outcome from outside the application. CAPToolkit generates the tools a LangChain or LangGraph agent calls from a CAP service's model, and CAPAgent is a ready-made ReAct agent over them. Because it is a client library pointed at a service that is already running, the service answering the question need not be one the project owns — the README draws that line against @cap-js/mcp, which requires owning the application and redeploying it.
Conditions: A Node.js host installs the library with zod, @langchain/core and a model package, as its install line names. It is pointed at a running OData V4 service: ODataExecutor is the client underneath. The agent loop is the project's own, unless CAPAgent is used, which the README scopes to demos and small apps.
Remaining work: Choose a tool strategy of minimal, crud, actions or full, which is where the README's four-hundred-tool argument bites, and build the loop, the prompt and the conversation's state, none of which this library carries.
a2a-pluginThe entry records that @a2a opts a service in and an agent handler answers, which would place it on this outcome, but nothing was retrieved on 2026-10-15 to say what the handler is given or what runs the loop.
Remaining work: Read the package's own documentation. npm answered 403 to the one address the entry carries and the package declares no public repository, so the README could not be reached in this pass.
Keep a conversation after the server restarts
A conversation with the agent survives a restart, and a follow-up that lands on another instance carries on where the last one left off instead of starting again.
Covers the state of one conversation between turns. What the agent remembers from an earlier conversation is a separate outcome; which database holds the rows is database connectors, keeping one tenant's rows apart is multitenancy, and how long a conversation may be kept is a data-protection question this record does not assess.
@cap-js/agentsThe harness keeps the conversation's short-term memory in the database the application is already connected to — SQLite in local development, SAP HANA in production — so conversational context and workflow checkpoints are written where the application's own data is. capire states this is what lets an agent resume a session after a server restart, and names clustered environments in the same sentence.
Remaining work: Nothing is installed for it; what remains is the deployment the claim depends on, a database the instances share rather than a local file, and a decision about how long a stored conversation is kept.
@mi8y/cds-langgraph-persistenceAnswers the same outcome for an agent whose loop is LangGraph's rather than the plugin's: checkpoints are thread-scoped state written through CDS, used to resume a workflow, keep the conversation's history and travel back through it.
Conditions: The agent runs on LangGraph, whose checkpointer interface this implements. @sap/cds 10 or higher, which its README states as a requirement. The README now says SAP's own @cap-js/agents includes checkpointer support and to prefer it for new applications, keeping this package available for its existing implementation.
Remaining work: The loop, the graph and the model stay the project's: this is the one piece of a LangGraph agent that the package supplies.
Require a person's approval before the agent acts
Before the agent runs an action that changes something, the task stops and waits for a person to approve or reject it, and carries on from there.
Covers holding the action and resuming the task. Who is allowed to approve is authorization, recording that they did is audit logging, and the screen the approval is given on is assessed on its own. An approval step modelled as a business workflow outside the agent is not this outcome.
@cap-js/agents@agent.hitl on a CDS action is the whole declaration. When the agent decides to call that action the task pauses and moves to A2A's input-required state instead of running it, and the plugin emits an AgentInputRequired audit event when the agent asks and an AgentTaskResumed one when the approval or rejection comes back. The same mechanism carries the execution-time quota: on a timeout the graph interrupts rather than failing and asks through the gate whether to continue, with a summary of the progress so far.
Remaining work: Annotate the actions that need it, and handle the input-required state in whatever talks to the agent — the pause is served over A2A, so the approving client is the project's. Nothing here decides who may approve.
Content
Show 4 more
Seen working
Neither the package manifest nor the repository tree declares a licence.
Neither the package manifest nor the repository tree declares a licence.
Details
Coverage
Designs that place it
Comparison properties
These are the questions used to compare what the artifacts do. Values come from their documentation and may apply to a particular ecosystem or runtime. Each recorded value in the comparison opens its statement and sources.
For your agent
- Ref
capability:agent-tooling- JSON
- /capabilities/agent-tooling.json
- MCP
- Connecting an agent