Moving an agent from a prototype to a shared service introduces decisions about execution, state, tools, data access, and support. This comparison helps teams evaluate trade-offs across configured agents, custom-code runtimes, and integrated document-to-agent platforms before selecting an operational deployment model. A platform comparison should follow those decisions through one real workflow. Product features help build a shortlist, but a deployment test is what shows whether the application can operate reliably in the intended environment.
Key takeaways
- Match the runtime to the application: A managed endpoint is useful only if it supports the required execution, state, and failure behavior.
- Keep interfaces distinct: Calling an agent through an API and letting that agent consume MCP tools are different integration tasks.
- Verify internal access explicitly: Identity, network paths, and tool permissions must fit the proposed deployment.
- Compare operating responsibilities: Hosting location alone does not tell you who handles upgrades, recovery, or incidents.
Start with the application and its execution model
A code-first approach lets developers define the workflow and choose the services around it. That flexibility is valuable for custom tools or approval steps. The team must choose a runtime and assign responsibility for operational controls; a managed service can operate the infrastructure while developers retain application logic.
Write down whether a task finishes in one request, continues asynchronously, pauses for a person, or resumes after a failure. Identify where state is stored and which external actions can occur. These requirements make runtime comparisons concrete.
A managed runtime may reduce infrastructure work while preserving custom application code. An integrated platform may cover more of the document-to-agent path. Neither choice removes the need to test the application's own behavior.
Compare managed runtime options by their documented scope
Microsoft Foundry Agent Service supports Prompt agents configured declaratively and Hosted agents built from customer code. Evaluate the mode that matches the application, including its tools, identity, networking, and observability options. Do not transfer a capability from one deployment mode to another without checking.
LangSmith Deployment supports multiple frameworks; verify the required integration path. The options below concern agent-runtime hosting. Managed BYOC contracts and observability-platform hosting require separate scope checks. Application teams retain responsibility for logic, permissions, and external side effects.
TABLE / Scroll horizontally for all columns →
| Platform & Option | Documented Scope | Suitable Workloads (Editorial Evaluation) | Internal Data & Authorization Verification | Operational Responsibility |
|---|---|---|---|---|
| Microsoft Foundry (Prompt agents) | Declarative agent setups using managed model catalog and built-in tooling | Standard assistant interactions and prompt-driven flows | Verification required (evaluate managed index and tool permission propagation) | Provider manages infrastructure and core service runtime |
| Microsoft Foundry (Hosted agents) | Containerized execution of custom application code and dependencies | Complex agent logic, custom state machines, and specialized libraries | Verification required (evaluate application network reachability and database authorization) | Shared: Provider manages host platform; team maintains application container and state logic |
| LangSmith Deployment (Cloud) | Provider-hosted control/data planes | Managed hosting | Verify credentials, network and source permissions | Provider operates runtime infrastructure |
| LangSmith Deployment (Hybrid) | Managed control plane; customer-hosted data plane | Customer infrastructure for execution | Same checks | Customer operates Agent Servers/data plane |
| LangSmith Deployment (Self-hosted with control plane) | Control plane and Agent Servers in customer Kubernetes | Control over infrastructure placement | Same checks; verify outbound dependencies | Customer operates deployed infrastructure |
| LangSmith Deployment (Standalone Agent Server) | Runtime without control plane | Teams supplying deployment management | Same checks | Customer operates server and dependencies |
| Seahorse Cloud (SaaS / On-Premises) | Integrated agent environment combining S3-compatible object storage, document parsing, semantic chunking, automatic vector DB sync, managed agents, and MCP tool calling | Document-centric workflows and unified retrieval-to-agent processes | Verification required (evaluate end-user ACL propagation across parsing, indexing, and retrieval) | Contract-dependent: Confirm upgrade, backup, incident-response and application-operation responsibilities for the selected offering in the contract |
For each option, confirm how an application version is built, promoted, observed, and rolled back. Then test an interrupted task. A platform that restarts a process does not necessarily restore the application's intended state or undo a partially completed external action.
Separate indexed retrieval, live tool calls, and data authorization
An integrated platform is worth evaluating when the application depends on repeated connections among document processing, retrieval, and agent execution. Seahorse Cloud (offered via SaaS or On-Premises) integrates agents with storage and document capabilities, including S3-compatible object storage, document parsing, semantic chunking, automatic vector database synchronization, managed agents, and MCP tool calling. The architectural boundaries between indexed document retrieval and live MCP tool calls must remain explicit.
In document workflows, source ingestion, parsing, indexing, and retrieval provide context for response generation. Live tool calls execute real-time operations or query external APIs directly. Vector similarity matching identifies relevant text chunks, but vector similarity itself does not grant or verify user access permissions.
Data authorization must be enforced through architecture-dependent database-native controls, metadata filtering, or application authorization before restricted content reaches the model or user. Post-generation filtering is insufficient to prevent unauthorized data exposure. Furthermore, retrieved document text represents retrieval data for context construction, not system instructions or authorization for tool execution.
Permissions and content change over time. Test whether permission changes prevent subsequent unauthorized access, separately from the timing of asynchronous index updates or cache clearing. Because indexing and cache updates carry propagation lag, teams should define and test explicit targets for permission propagation lag and content freshness. When user authorization status is uncertain, the application should revalidate access and fail closed. Previously disclosed output cannot be un-sent, so authorization checks must occur prior to synthesis.
For citations of modified or deleted documents, the system must evaluate source and version validity along with access permissions. Exclude unauthorized or unavailable material through source and authorization checks. Historical versions may be cited only when accessible, authorized, and clearly labeled under the application’s policy; model refusal alone is not an access-control mechanism.
Separate client APIs, MCP tools, and authorization
An application may call an agent through a service API. The agent may then use an MCP connection or another API to access tools. These are separate boundaries with separate identities and permissions.
Draw the flow from the user interface to the agent and from the agent to each internal service. Identify which credential is used, how its scope is limited, and whether the operation acts for the user or a service account. Avoid passing one broadly privileged identity through the entire workflow without an explicit design.
MCP support does not establish access to every internal tool, a universal central registry, or permission to perform every action. Confirm compatible interfaces, tool definitions, authentication, and network reachability for the selected components. Tool access also does not prove that the agent will choose or use the tool correctly.
Run a deployment acceptance test
Use a test environment with synthetic data and controlled tools. Evaluate key operational metrics during testing: p50 and p95 latency, task success rate, recovery time per test scenario, required operator hours, and cost per successful task (inclusive of failed attempts and retries over the test period).
According to the LangChain State of Agent Engineering survey (November 18 – December 2, 2025; 1,340 respondents), 62% of respondents report using detailed tracing and 52.4% use offline evaluations. These figures describe respondents to a vendor-run, self-selected survey, not an industry-wide census or evidence of performance improvements or cost savings.
The following cases are proposed acceptance tests, not published performance results.
TABLE / Scroll horizontally for all columns →
| Scenario | What to observe |
|---|---|
| Deploy a new application version | Version identity, configuration, and review process |
| Call an internal tool | Identity, network path, authorized operation, and result |
| Reject an invalid tool request | Clear error handling and safe agent response |
| Interrupt long-running task / retry write actions | State recovery, write side-effect reconciliation, and duplicate action prevention |
| Increase concurrent requests | Queueing, p50/p95 latency, limits, and failure behavior |
| Revert a faulty release | Previous version availability and state compatibility |
| Exceed a test usage threshold | Alerting and separately configured enforcement mechanisms |
| Revoke user read access | Permission propagation lag and fail-closed behavior on uncertain access |
| Modify or delete source document | Content freshness lag, index update timing, and source version validity |
| Inject malicious instructions in document or tool response | Evaluate whether untrusted text causes unauthorized actions, disclosure, or policy changes, and record failures |
Record the configuration and the operator steps required to recover each failure. Agree on application-specific pass criteria before running the comparison. A successful demonstration with one user does not establish the expected behavior under concurrent production traffic.
Assign responsibility before choosing a platform
List who maintains tools, rotates credentials, updates source connections, reviews traces, and responds to incidents. Include what the provider manages and what remains with the application team.
Separate hosting location, operating responsibility, and the commercial arrangement. Customer-hosted software can involve provider operations under contract; provider-hosted software can still leave application maintenance with the customer. Inspect network dependencies independently if the environment restricts outbound access.
Choose the deployment that meets the tested workflow with responsibilities the team can sustain. Keep the acceptance record as a baseline for future releases and source changes.
FAQ
Does a managed runtime remove the need for application state design?
No. Confirm what the runtime persists and how the application recovers, especially when tasks call external systems.
Does MCP support mean an agent can access any internal system?
No. The required tool interface, credentials, authorization, and network connection must still be configured and tested.
Is an on-premises deployment automatically disconnected from external services?
No. Inventory and test dependencies such as models, authentication, telemetry, and update services under the intended network policy.
How should permission revocations and document updates be verified during deployment testing?
Define propagation lag and content freshness targets. Test whether revoking a user's access denies subsequent queries and fails closed when permission status is uncertain. Verify that updated or deleted documents reflect defined index refresh targets and that source version authorization is checked before generating citations.