Inside a governed product agent.

The product pack carries the domain.

A product has its own vocabulary, tasks and capabilities. The pack boundary gives that domain behaviour a defined place without requiring it to become part of a general-purpose runtime. Published contracts provide the connection between the product and the framework.

An integration starts by deciding what belongs to the product: its business rules, domain information and available actions. The framework should not need to understand every industry to host a product agent, and a pack should not bypass the host’s execution boundaries to reach an external system.

Authority comes from the application context.

The runtime needs to know which user, session and product context a request belongs to. Authentication and allowed capabilities are application responsibilities carried into the agent workflow; they are not permissions the model can grant itself.

Sarva’s framework surfaces include session hosting and an authority-verification boundary. A technical evaluation should show how the integrating application establishes identity and scope, how that context reaches tool execution and how an out-of-scope request is handled. These checks are specific to the chosen integration.

• Product and session identity
• Permitted capabilities and information scope
• Approval requirements for consequential actions
• Evidence tied to the action and its result

ToolGateway is the action boundary.

A proposed action is different from permission to perform it. Sarva routes tool execution through a governed boundary that can apply the configured policy, approval and idempotency requirements. Product tools should expose a clear contract and return an outcome that can be inspected.

The important demonstration follows an action through that boundary. Inspect the requested operation, the authority under which it ran and the external result. Where approval is required, the workflow should show the decision before execution. Where a request is retried, duplicate-effect prevention needs evidence in the intended connector path.

Persistence makes continuing work explicit.

Some tasks span several turns or wait for a person. Persistent state, checkpoints, scoped memory and worker surfaces support those pauses and continuations. Remembered context helps the task continue; it should not silently widen what the agent is authorised to do.

Traces and recorded outcomes help engineers understand what happened across a run. Sarva includes a NOOA binding and related Karta dependencies. Those are implementation relationships, not a claim that every DataVedam product already runs on the same runtime. Framework adoption and deployment remain product-specific decisions.