Tray.ai makes governed workflows available to people and agents

Tray.ai is an integration platform whose workflows can also become tools for AI agents. Its appeal is strongest when a business already needs dependable cross-system processes and wants agents to use those processes through a governed interface. The key question is not how many connectors appear in the catalog. It is whether the organization can define an action precisely enough that both a person and an agent can invoke it safely and understand its result.

01 / ProductAn integration platform with two agent interfaces

Tray's current offering brings together automation and integration, Merlin Agent Builder and Agent Gateway. Merlin creates agents from a scope, data sources, a model and workflows exposed as tools. An agent workflow coordinates those components. The Merlin overview² presents a Tray agent as a project built from these parts, which is useful context for teams expecting an agent to be a single prompt attached to a connector.

Agent Gateway serves a related but different purpose: it exposes tools through the Model Context Protocol, or MCP, so compatible AI clients can invoke them. An organization can therefore maintain a business workflow in Tray and make that capability available through an external agent interface. The workflow remains the place to encode required inputs, service calls and the meaning of a completed action.

This creates a useful separation between choosing an action and implementing it. An agent may decide that a customer needs a delivery investigation; the maintained workflow should determine which systems are queried and what evidence is returned. Letting the agent invent a fresh sequence of unrestricted connector operations for every request would surrender much of the consistency that the integration layer can provide.

02 / AudienceBest for organizations with integration ownership

Tray is most relevant to integration teams, business systems teams and platform groups that support multiple departments. These teams often need shared credentials, development conventions, execution logs and a way to reuse business logic. The AI opportunity builds on that work: a well-defined workflow can become a reusable tool instead of remaining accessible only through a form or scheduled trigger.

It is a heavier choice for a small team that needs a few familiar actions and has no appetite for an enterprise agreement. Make's blueprint offers a useful comparison for visual automation with a different buying model. Workato's blueprint is the closer comparison when integration governance, operational ownership and enterprise deployment requirements dominate the shortlist.

The deciding factor should be the number and importance of maintained business capabilities, not the number of people who want a chatbot. A company with five consequential cross-system actions can need more integration discipline than one with hundreds of read-only assistants. Tray is most persuasive when that discipline already has an owner and the agent interface makes existing capabilities easier to use.

03 / WorkflowTurn one business capability into a constrained tool

A proposed pilot is a delivery-investigation tool for account managers. Give it an order identifier and an allowed customer context. The workflow checks the order system, reads shipment events and returns a structured account of what is known, what conflicts and which team owns the next step. Start with a read-only tool before adding actions such as creating an investigation ticket.

Do not make a broad tool called “manage orders” with a free-text instruction and access to every connector operation. A narrow “get delivery investigation” capability can require an order identifier, refuse an unsupported customer relationship and return a predictable result.

Choose credentials for each service call

The authentication and access guide³ distinguishes how an AI client connects from how tools authenticate to business services. OAuth2 connections can support user-provided authentication. API-token clients use service-account credentials and cannot prompt a user to supply personal credentials. An account manager signing into a client does not, by itself, mean every downstream call uses that manager's permissions.

For the pilot, decide separately whether the order lookup and ticket creation should use a shared account or the requesting employee's account. A shared account may be appropriate for a centrally maintained lookup, while ticket creation may need an individual author. The correct combination depends on the source systems' permission model and audit expectations. Document that choice in the tool contract so the result's apparent author is not misleading.

Make outcomes explicit before adding writes

Return separate fields for order found, shipment evidence, unresolved conflict and recommended next step. If the carrier lookup fails, do not present the absence of tracking data as proof that nothing shipped. A partial response can still be useful, provided the tool says which part is unavailable and the agent preserves that distinction in its answer.

When ticket creation is introduced, give the request a stable investigation identifier and return the destination ticket identifier. A user asking twice about the same unresolved shipment should not unknowingly create two investigations. Keep the lookup and the write logically distinguishable so a repeated read remains cheap to reason about, and a repeated write can be reconciled against an existing operation.

04 / PricingEnterprise pricing depends on platform scope and usage

Tray's pricing page¹, accessed 15 September 2026, lists Pro, Team and Enterprise with custom commercial terms. Tasks measure usage across platform capabilities. Agent Development is presented as an add-on that includes Agent Gateway and Merlin Agent Builder. A platform subscription should therefore not be assumed to include every agent capability without checking the quote.

The useful budget discussion starts with a workload model: ordinary investigations, investigations requiring extra lookups and repeated requests during a carrier outage. Estimate how many underlying operations each path performs and ask Tray to map those paths to billable Tasks. A simple average can hide the expensive path precisely when the business is busiest and source systems are least reliable.

Also compare the operating features attached to the plan. Retention is a practical example: if a dispute commonly arrives weeks after a shipment, a short default log window may not preserve the evidence an investigator expects. The right answer could be a longer retention option or a separate business record containing the relevant facts. Buying a larger plan is not a substitute for defining which evidence must outlive execution logs.

05 / DistinctionsGovernance depends on distinctions the interface exposes

Tray's access model separates permission to invoke an MCP server's tools from workspace membership. A user explicitly added for execution does not automatically need the ability to inspect or modify the underlying workflows. Conversely, workspace roles can carry broader visibility or editing rights. The access documentation³ makes this an important configuration decision when distributing tools to a large business audience.

Dynamic authentication has another operational detail: credential mappings are scoped to an MCP session and last up to seven days; disconnecting and reconnecting creates a fresh session. Changing an authentication's mode can affect every tool in the workspace that shares it. The dynamic authentication guide⁴ explains why a credential change needs to be reviewed as a shared dependency rather than a local setting on one demonstration tool.

Those distinctions are valuable because they make different responsibilities visible. The person authorizing a client connection, the person maintaining a workflow and the account executing a service call may be different people. A well-operated deployment can preserve all three relationships. A loosely configured deployment can make them appear interchangeable even though the downstream systems will treat them differently.

06 / QuestionsError continuation can change the meaning of success

Tray supports manual connector-level error handling and a Continue Workflow option. Its error-handling guide⁵ cautions against continuing when later steps require data from the failed step. This is especially relevant when an agent consumes a final response: the presence of a response is not sufficient evidence that all the underlying business checks succeeded.

For the delivery tool, deliberately test an unknown order, an expired carrier connection and a response that lacks the expected shipment field. The desired output differs in each case. “Order not found” is a business result, “carrier unavailable” is a partial investigation and “unexpected response shape” may indicate an integration change. Combining them into one friendly sentence would make the agent easier to demo and harder to trust.

Review the real client experience for user-provided authentication as well. Some clients can resume after the user maps credentials; others may require a further prompt. A permission warning can also indicate a scope mismatch without preventing the user from proceeding. The dynamic-authentication documentation describes these behaviors, so the pilot should include the exact client and credential combination employees will use.

07 / DecisionChoose Tray when reusable business actions are the asset

Tray is a strong candidate when maintained integrations are becoming a shared tool layer for multiple agents and departments. Its practical advantage is the opportunity to reuse workflow logic, credential controls and operational evidence across interfaces. The organization still needs to define a small set of capabilities with clear inputs, permissions and outcomes.

Begin with one read-only investigation and a deliberately incomplete result, then add one reconciled write. Compare the effort of maintaining that capability in Tray with the alternatives and map actual execution paths to the commercial proposal. Expand only after employees can distinguish a complete answer, a partial answer and a failed action without inspecting the entire workflow themselves.