Questions we get about
AI Agent adoption

Fixed-price per project: a single quote for the full project scope, paid in stages at milestones agreed in the proposal, with no subscription commitment. The initial diagnosis is free.

The quote follows the diagnosis and is based on scenario complexity and the volume of system integration. POC validation, build and integration, production deployment, and handover are separate stages, and at the end of each stage the enterprise decides whether to proceed to the next; the deliverables and investment level for each stage are set out in the post-diagnosis proposal.

Delivery runs in five steps: (1) assess, (2) validate a POC (optional), (3) build and integrate, (4) deploy to production, (5) hand over to your team.

The timeline depends on the complexity of the scenario, the volume of data and systems to integrate, and whether private deployment is required; the schedule is agreed in the proposal for each specific scenario. We recommend starting with a free AI adoption diagnosis: describe the business scenario, and an AI Agent returns feasibility, architecture suggestions, and an adoption path on the spot, which then informs scope and timeline.

Deliverables build up by stage: the POC stage delivers a runnable prototype, the agent architecture with model selection recommendations, and the acceptance criteria; development and deployment deliver the custom project source, tests, and deployment scripts; handover delivers runbooks, SOPs, and team training.

Acceptance criteria are established during the POC as a versioned EvalSet with reference samples, forming an acceptance baseline and a Go / No-Go recommendation; each subsequent stage is accepted against that baseline. Because the system runs on open-multi-agent, every run keeps execution receipts and traces, the Run Viewer can replay the task DAG, and the acceptance report is grounded in those run records.

Three: a business owner who can define the process and the acceptance criteria, the data and system access required for the pilot scenario, and a technical lead responsible for integration and the deployment environment.

The business owner is most involved during diagnosis and the POC, confirming process boundaries, supplying reference samples, and signing off on acceptance criteria. The technical lead joins during integration and deployment, providing interface details for CRM / ERP / internal APIs, the deployment environment, and account permissions. At handover, the receiving team attends training and takes over the runbooks. After go-live the system is maintained by the enterprise's own team, with ongoing iteration and operations support agreed separately as needed.

Yes. open-multi-agent is a Node.js library embedded in the enterprise's own backend and runs entirely within its own process; with on-premise models served by Ollama, vLLM, or LM Studio it requires no API key and runs fully offline or air-gapped, so data stays inside the network.

The framework opens outbound connections for one purpose only: reaching the model endpoint the enterprise configures, and all persisted data is written to storage the enterprise provides. With cloud models, business data reaches only the model provider the enterprise has selected; the egress policy can be set to offline, permitting loopback origins only, or allowlist, permitting only the specified domains, and policies at each level intersect. YuanASI delivers complete private-deployment engagements and on-premise model selection, placing the models, orchestration, and business systems within the enterprise's own environment in line with its compliance requirements and hardware.

The execution boundary is written into the code: consequential actions such as writing files, modifying business-system data, or sending external messages enter an approval step before execution, where designated staff allow or reject them; matters the agent cannot resolve within a set number of attempts or budget are routed to a person under predefined rules.

open-multi-agent provides approval hooks at three boundaries: plan generation, task dispatch, and tool calls. Tools are default-deny and released call by call, and approval decisions are stored durably and bound to the reviewed content; timeouts, retries, loop detection, and token / cost budgets bound the scope of every run. The commission reconciliation example among our open-source examples illustrates this pattern: repair what can be repaired, and hand the rest to a person. When an error occurs, execution receipts and traces pinpoint the specific task and tool call, so both sides can review and correct it.

Yes. The business process, prompts, and evaluation samples validated during prototyping are all valid inputs; on that basis we complete the code-level implementation, system integration, and production deployment on open-multi-agent.

For prototypes built on low-code platforms, the usual signals for moving on are constrained customization, internal systems that cannot be reached, the need for tests and version control, the need for private deployment, or costs that must be controlled at scale. For prototypes built on open-multi-agent or another code-level framework, the focus is engineering hardening: stability, performance, observability, and team handover. Both paths begin with a diagnosis that confirms what the prototype has already validated and what remains, before the scope is set.

Split ROI into two sides: benefit = person-hours saved per run of a scenario × frequency × labor cost; cost = one-time development plus the ongoing cost of model calls and operations.

We recommend piloting one high-frequency, well-defined scenario, filling the formula with real operating data, and then deciding whether to expand to further scenarios. open-multi-agent returns token usage on every run and supports a cost budget ceiling, so the cost side has measured figures from the first day of the pilot and the ROI assessment rests on data.

open-multi-agent (OMA) is the open-source multi-agent orchestration framework developed by YuanASI for TypeScript backends. A business goal is handed to the Coordinator, which decomposes it into a task DAG at runtime; a deterministic scheduler executes the DAG in parallel, and the entire run keeps a record that can be inspected, approved, and replayed.

The framework offers three modes: runTeam() plans from a goal, runAgent() runs a single agent, and runTasks() executes a predefined pipeline. The core package has 3 runtime dependencies (@anthropic-ai/sdk, openai, zod), requires Node.js 20 or later, and embeds directly into any Node.js application. It was released in April 2026 under the MIT license and installs with npm install @open-multi-agent/core.

Model selection rests with the enterprise. Anthropic, OpenAI, Gemini, Azure OpenAI, and AWS Bedrock, together with Chinese providers such as DeepSeek, Doubao, Hunyuan, MiniMax, and MiMo, are integrated natively; Qwen, Zhipu, Kimi, and on-premise models served by Ollama or vLLM connect through OpenAI-compatible endpoints, and Vercel AI SDK providers are supported as well. The model used in a given project is settled during solution design, based on compliance requirements, cost, and measured results.

LangGraph and Mastra require developers to author the workflow graph node by node; Dify and Coze are visual low-code platforms; open-multi-agent has the Coordinator generate the task graph from the goal at runtime, with approvals, replay, and tracing built in.

LangGraph follows a graph-first model: nodes, edges, and conditional routing are defined up front and compiled, its first-party TypeScript package is generally available, and it provides state history and time travel over the graph. Mastra is likewise TypeScript-native, bundling memory, RAG, evaluation, and a studio, while workflow graphs are still written by hand with .then() / .branch() and the core carries roughly 32 direct dependencies. CrewAI targets Python and organizes agents into role-based crews. AutoGen has entered maintenance mode, and Microsoft directs new projects to the Microsoft Agent Framework. Dify and Coze produce a working prototype within hours, and Coze Studio is now open source under Apache 2.0 with self-hosting support; once a project reaches deep customization, complex integration, and engineering practice (tests, version control), a code-level framework is usually required. open-multi-agent operates at the orchestration layer and suits scenarios where several agents, task dependencies, approvals, or recovery mechanisms must work in concert; where a single agent call suffices, an LLM SDK alone is adequate. A point-by-point comparison is available on the compare page of the open-multi-agent website.

The criterion is whether the task can be decomposed and whether it calls for division of labor: a linear, single task is simpler with one agent; multiple agents are warranted when the goal can be broken down and several roles need to work in parallel.

open-multi-agent provides a tiered API: runAgent() is one agent with one prompt; runTasks() lets developers define the task graph themselves; runTeam() takes a goal and has the Coordinator decompose it into a DAG for parallel execution, with a deterministic router first deciding whether the goal goes to a single agent or the whole team; runConsensus() cross-verifies through a proposer→judge pass. Select the tier that matches the task's complexity; a project that starts with a single agent can be upgraded to a team at any time.