Run the agent where your controls belong.
Use the same Silvana agent logic across infrastructure models that place operations, secrets, signing, and governance in different boundaries.
Same agent logic. Different operating boundaries.
The runtime defines the control model.
Choosing where an agent runs determines who operates it, where data is processed, how secrets are protected, where signing occurs, and how the system is monitored and governed.
Agent logic
The strategy, workflow rules, integrations, and decision model executed by the runtime.
Identity and secrets
The credentials, keys, tokens, and configuration required to access services and authorize supported actions.
Signing boundary
The environment in which prepared transactions are reviewed and signed.
Data boundary
The location in which market data, private strategy inputs, application context, and operational state are processed.
Network boundary
The endpoints, egress rules, service access, and connectivity policy available to the agent.
Operating responsibility
The team responsible for deployment, updates, monitoring, scaling, incident response, and recovery.
Choose the boundary that fits the mandate.
The same agent can move through different runtime models as security, scale, confidentiality, and operating requirements change.
Self Hosted
Run the agent in infrastructure your organization owns and operates. Your team controls the environment, networking, deployment process, secrets, monitoring, and governance.
Cloud Deployment
Deploy the agent in your cloud account or approved cloud project. Use cloud native scaling, networking, secrets, and operations while retaining ownership of the application environment.
Silvana Managed
Run the agent in a Silvana managed environment when speed to deployment and reduced infrastructure overhead are the priority.
Trusted Execution Environment
Run supported agent logic and secrets inside a trusted execution environment when the workflow requires stronger isolation from surrounding infrastructure.
Choose by control, not convenience alone.
Security perimeter
Decide whether the agent must remain inside your infrastructure, your cloud account, an approved managed environment, or an isolated runtime.
Signing and key custody
Define where private key material exists, which process can request a signature, and who can change the signing policy.
Data sensitivity
Identify which strategy inputs, customer information, market context, or workflow state the runtime is allowed to process.
Operational ownership
Assign responsibility for releases, uptime, scaling, monitoring, incident response, and recovery.
Scale and availability
Estimate the workload, service level, regional, redundancy, and performance requirements of the agent.
Governance and audit
Confirm which logs, approvals, configuration history, access controls, and evidence the organization must retain.
Integration dependencies
Document every external model, data source, wallet, service, network, and internal system the runtime must reach.
Keep strategy logic separate from settlement infrastructure.
Standard agent architecture
A standard Silvana agent uses typed services to observe state, initiate supported actions, authorize transactions, and follow the result. The runtime does not need to rebuild the full Canton integration for every workflow.
Agent path
Agent logic
Applies the strategy, mandate, policy, and workflow rules defined by the operator.
Silvana SDK or gRPC clients
Connects the runtime to orderbook, settlement, ledger, pricing, and supported signal services.
Verification and signing
Reviews prepared transactions and authorizes them inside the approved runtime boundary.
Silvana execution services
Coordinate the supported order, transaction, and settlement workflow.
Canton
Provides the privacy and settlement foundation for final asset state changes.
The standard Silvana Book agent path routes supported ledger operations through Silvana services rather than requiring each agent to build a direct Canton integration.
Deploy through a controlled sequence.
Package the agent
Version the code, dependencies, runtime requirements, and configuration schema used by the deployment.
Select the environment
Choose the deployment model and document the control, data, signing, and operating boundaries.
Provision identity and secrets
Create the agent identity and supply credentials through the approved secret management process.
Configure permissions and limits
Define the services, operations, assets, markets, size, exposure, and runtime rules available to the agent.
Connect and validate
Confirm network access, service discovery, authentication, event streams, signing, and nonproduction workflow behavior.
Launch the runtime
Start the agent with the approved version and configuration. Record deployment identifiers and ownership.
Observe and operate
Monitor health, events, actions, settlement state, errors, usage, and configuration throughout the runtime lifecycle.
Deployment should preserve the control model.
Least privilege access
Expose only the services, operations, assets, markets, data, and network destinations required by the mandate.
Protected secrets
Store credentials and private material through the secret system approved for the selected runtime.
Transaction verification
Review prepared state changes before signing rather than giving the agent unrestricted authority.
Defined signing policy
Document which identity signs, where signing occurs, and which operations the signing environment will approve.
Configuration governance
Version strategy parameters, permissions, limits, endpoints, and environment changes.
Network policy
Control connectivity to Silvana services, approved data sources, models, monitoring, and internal systems.
Stop and update controls
Provide a documented way to pause, replace, roll back, or retire the runtime when conditions change.
Treat the agent as an operating system component.
Health and readiness
Expose whether the runtime is connected, authenticated, synchronized, and ready to act.
Event and action logs
Record identifiers, decisions, requests, signatures, status changes, and errors required for support and review.
Monitoring and alerts
Detect connectivity loss, stalled streams, repeated failures, limit breaches, signing issues, or abnormal runtime behavior.
State recovery
Persist the information required to reconnect, resume from a known point, and reconcile incomplete workflows.
Version management
Know which code, SDK, schema, model, and configuration version each runtime is using.
Secret rotation
Define how credentials and signing material are rotated without losing control of active workflows.
Incident response
Assign who can pause the agent, revoke access, change configuration, inspect activity, and restore service.
Capacity planning
Monitor request volume, event throughput, resource use, latency, and external dependency limits as the workflow grows.
Match the runtime to the operating reality.
Take the same agent from first run to an operated runtime.
Capture the decisions before infrastructure is provisioned.
Qualified teams can use a short deployment brief to begin selecting an architecture.
Put the agent in the right boundary.
Start with a working agent, choose where logic and authorization belong, and operate the runtime with clear ownership from the first deployment.