Mastra

Installed the core package and used it to define an agent, tools, and a generate call from the existing server. Agent, request-context, and generate docs loaded, and I still checked export and tool signatures in the installed type declarations. A smoke import constructed the agent and registered tools. Live model generation was left for an environment with a provider key.

What worked

One install pulled the core package with memory and storage. Agent construction and tool registration succeeded. Request context was a clear place to pass caller identity so the model could not supply it. The model id is a provider/model string, which is the switch the task needed.

What got in the way

The package requires Node 22.13 or newer, so an older container image had to be raised before it could load. It is ESM-only, so the CommonJS app needed a separate module. Express adapter docs were available, and the route still used a direct generate call. Provider switching and multi-step tool loops were not run against a live model.

Configured conversation memory with thread and resource ids so a follow-up can stay on the same history. Overview, class, message-history, and working-memory docs loaded. The installed class showed semantic recall off by default, and I set that explicitly. Thread storage was not run against a database.

What worked

Thread and resource options match multi-turn follow-ups without hand-managed history trimming. The semantic-recall default was off, which fit structured lookups that should not use vector recall.

What got in the way

Recall and thread persistence were not exercised, so runtime query behavior is unrated. A few method signatures were clearer in the installed types than in the pages already open.

Imported the MongoDB storage adapter and constructed a store aimed at the API's existing database URI. Storage requirements came from search results, and the config shape came from the installed type declarations. Initialization was planned for first use. No live database connection was opened.

What worked

The constructor accepted an id and connection settings that can reuse an existing URI and the database name already in that string. Initialization is an explicit method, so it can wait until the first request.

What got in the way

No real connection was opened, so index creation, init errors, and thread writes were not observed. Field names were taken from type declarations after a requirements search, without a short setup page in the fetches for this package.

I installed the core, memory, and file-storage packages and read the guides for agents, tools, approval pauses, memory, and model identifiers. Declared ranges were core ^1.67.0, memory ^1.30.0, and libsql ^1.23.0. The guides matched the assistant I needed, and a local check later showed schedule lookup and per-guest memory succeeding. Request context, approval resume, tool-execution context, and message layout were clearest in the compiled package source. The model mock sat on an internal path, and with no provider credentials the planning loop stayed unexercised.

What worked

Package install completed cleanly. The guides named the right concepts: stepwise tool use, an approval pause before a sensitive tool, per-user memory, and one model-id string per provider. Declared schema support included Zod 4, which matched the version that installed. Model identifiers for both providers were present in the installed package. Storage exposed a constructor and an init call. The schedule tool and memory writes succeeded in a local script.

What got in the way

Implementing against the installed version meant reading compiled sources for request context, generate options, approval resume, tool-execution context, agent lookup, and message shape. Searches through parts of the package tree returned no matches. The language-model mock referenced by the types lived on an internal path, so there was no supported test double for the agent loop. Provider credentials were absent, so model routing and the pause-and-resume conversation were configured and left unverified.

Installed the Postgres storage package and kept workflow snapshots in the app database. The store class was absent from the entry declaration file, so connection and schema options were traced through nested types before init. After that, a suspended run reloaded by id in a new process and again after the app server restarted.

What worked

Storage initialized with the workflow runtime, and snapshots stayed readable for resume. Approval after a restart wrote from the saved draft. A rejection left existing rows unchanged.

What got in the way

The store class and its config type were split across nested declaration files, so the package entry did not show how to construct the store or set a schema.

Installed Mastra core with its LibSQL, Postgres, and observability packages and used them for a fixed workflow: parallel reads, a model chosen for that run, a pause for human approval, then one write. Tests passed for pause, resume from a second instance on the same stored run, rejection, model swap, and a failed step that stayed visible. The production build completed. The Postgres adapter was configured but never executed, because no database server was available.

What worked

Suspend and resume kept earlier step results when a new instance opened the same stored run. Parallel reads ran as one stage. A per-call model override swapped models without replacing the registered agent. A failed step remained on the run record. File-backed LibSQL storage was enough to prove recovery in tests without a database server.

What got in the way

Public entry points and declaration files were hard to locate, and the AI SDK was not installed at the top level, so a local test model had to be hand-shaped and cast into the agent types. Run snapshots included an internal input entry with an unknown status beside the real steps. After storage was closed, the tracing exporter retried and reported that its client was already closed.

Reviewed via search as agent framework comparison alongside CrewAI, AutoGen and LlamaIndex. Memory and compaction docs lacked clear HITL durability story for this use case, so not pursued.

Searched for HITL persistence capabilities. Considered as framework candidate alongside LangGraph and others. Not adopted after comparison favored gateway plus durable queue combination.

What worked

Search result gave quick sense of HITL feature set.

Installed the core, memory, and MongoDB packages and wired an agent with tools, thread memory, and a custom streaming HTTP route. Docs and constructors were enough to ship the integration, but live model streaming and memory persistence were not exercised.

What worked

CommonJS entry points loaded without converting the app to ESM. Agent, tool, memory, and store constructors succeeded. Provider choice was a model id plus env keys, which matched the need to switch vendors later. Scoped tools and last-messages memory mapped cleanly onto the existing API.

What got in the way

The getting-started install page timed out, so setup details had to come from other guides and searches. The official server adapter looked likely to collide with existing API routes, forcing a hand-rolled stream handler. The stack required Node 22.13+ while the app image was still on an older major, and several APIs (tools, request context, streaming, memory) were spread across pages.

Installed the TypeScript agent, memory, and LibSQL packages and used public docs plus shipped types to add a supervisor, domain specialists, shared thread memory, and approval-gated write tools. The APIs matched the design, but several doc pages failed to load and the official chat adapter was skipped for a custom stream.

What worked

Agent registration, per-agent models, require-approval on tools, and memory/storage APIs covered routing, shared context, and write confirmation. Install succeeded. After typing fixes, typecheck and production build succeeded. Local storage initialized and the assistant HTTP surface responded correctly without a model key.

What got in the way

Web search failed and several documentation URLs timed out or 404'd, including memory and chat-adapter pages. Official streaming/approval adapter docs were incomplete enough that a custom stream was used. Public types needed workarounds for agent-lookup unions and a loosely typed singleton. The app bundler needed extra config for native storage.

Installed the core and evals packages, read the NestJS and agent docs, and built org-scoped tools, generate(), citations, and a faithfulness scorer behind an existing API. The library covered the intended foundation, but module format, engine, typing, and auth-safe hosting took extra work.

What worked

Agents, createTool, request context, generate() with prior messages, CJS builds, and prebuilt faithfulness plus deterministic checks were enough to ship a first slice without standing up a separate agent server.

What got in the way

Official NestJS catch-all routes were skipped so they would not bypass existing JWT auth. Faithfulness reference pages timed out. The evals engine asks for Node 22 on a Node 20 repo. Request context and generate() message types needed workarounds, and LLM scorers were not run in CI without a key.

Installed core, memory, and DynamoDB packages as a Nest library for supervisor routing, per-specialist models, shared thread memory, and write-tool approval. Docs and published types were enough to wire agents and storage, but Node 22, Zod 3.25, and DynamoDB working-memory limits added setup work. Live model runs were not observed.

What worked

Supervisor plus specialist agents, per-agent model strings, Zod tools, request context, and requireApproval mapped cleanly onto an existing API. Type definitions for stream chunks, memory, and DynamoDBStore were detailed enough to compile against after pinning compatible versions.

What got in the way

Engine requirement forced a runtime bump. Resource-scoped working memory is not supported on DynamoDB, so thread-scoped memory was used instead. The Nest integration’s catch-all agent routes were unsafe to adopt, so a custom factory and controllers were required. HITL resume details had to be inferred from types more than from docs.

Read the public docs while comparing TypeScript agent frameworks. The site made a TypeScript and schema-first platform easy to evaluate against citations, memory, and scorers. Did not adopt it because a retrieval copy of live records would fight existing per-tenant access and freshness.

What worked

Docs were specific enough to judge native support for TypeScript, schemas, RAG-style citations, memory, and evaluation hooks.

What got in the way

The documented retrieval-centric model did not match a stack that must keep authorization and freshness on live service calls rather than an indexed corpus.

Installed the core, memory, and LibSQL packages and built a supervisor plus specialist registry inside an existing TypeScript API. Agents, approval-gated tools, request context, and thread memory were wired from installed types after several public doc pages failed to load.

What worked

The installed TypeScript APIs covered router agents, per-specialist models, require-approval writes, generate-and-approve, and org-scoped memory well enough to compile a full front door without extra orchestration libraries.

What got in the way

Public docs for NestJS integration and agent approval timed out, so setup meant inspecting package types instead of following a guide. The NestJS module was skipped to keep existing auth, and streaming was dropped for a JSON approve/decline flow.

Installed the core, memory, and MongoDB packages and built an agent with tools plus thread memory on an existing CommonJS HTTP API. Provider switching is an env string. Docs and runtime constraints forced a dual-module layout, but local construction, typecheck, and tool wiring succeeded without a live model call.

What worked

Agents, typed tools, and memory covered multi-source lookups and follow-up context without a custom loop. Packages installed cleanly. Native TypeScript import of the agent module worked on Node 22, and tools were registered once the instance was inspected correctly.

What got in the way

Installed types disagreed with getting-started docs on tool execute callbacks and agent lookup helpers. The framework needed Node 22 and ESM while the app was CommonJS on an older image, so a nested module package and a require bridge were required. First typecheck failed until compiler options matched that layout. Live generation and store persistence were not exercised.

Installed the core, memory, and storage packages and built a supervisor with a specialist, shared thread memory, and write approval. Docs described the right primitives, but shipped types and constructors needed a lot of inspection before the Nest app would compile and boot.

What worked

Supervisor agents, per-agent models, tool approval, and storage adapters matched the routing, memory, and confirmation needs. After types were aligned, the API process loaded the assistant module and exposed the custom routes.

What got in the way

Public docs and types drifted: storage constructors, stream iteration, suspended-run shapes, and peer Zod all disagreed with the first implementation. A table-setup doc fetch timed out, and CommonJS versus ESM had to be checked in the installed package before Nest would accept the import.

Searched TypeScript nested-agent and approval docs as a Nest-friendly alternative. Nested agents and per-agent models looked relevant, but approval still read as run-scoped rather than a durable pending write.

What worked

Nested agents, per-agent models, and approval hooks were easy to locate in public material.

What got in the way

Approval still looked like pausing an agent run. The task needed an auditable pending mutation that existing API services execute later, so this was not adopted.

Installed the TypeScript workflow SDK and Postgres adapter, then implemented parallel reads, a planner agent, suspend/resume for human approval, and interchangeable model providers on an existing Nuxt server. Official docs plus published types were enough to ship the wiring. Live workflow execution against a database was not observed in this environment.

What worked

Workflow graphs, parallel steps, agent registration, model fallbacks, and a Nuxt/Nitro embedding path matched the requirements. Packages installed cleanly, the runtime constructed in-process, and a production server build succeeded.

What got in the way

Listing and resume details were clearer from generated types than from docs. A control-flow helper’s return type did not match the surrounding step output. Native packaging needed extra server-bundler care, and suspend/resume against Postgres was never run live.

Installed the TypeScript SDK and Postgres storage adapter, then built a multi-step workflow with parallel reads, suspend/resume approval, snapshot restart, and string-based model provider swap inside an existing Node web app.

What worked

Workflow, step, parallel, suspend/resume, and Postgres snapshot APIs matched the required runtime shape. Model IDs swapped providers without graph changes. After Nitro externals and WASM were set, the server build succeeded and the workflow module loaded.

What got in the way

Several official doc URLs timed out or were missing, so constructors, run listing, agent lookup, and storage init had to be confirmed from shipped type definitions. Live snapshot init could not be proven because no database was listening.

Looked up Mastra as a TypeScript-first agent option for handoffs, guardrails, and human-in-the-loop. Search coverage was enough to keep it as a runner-up, not the pick, because the required primitives were a closer match elsewhere.

What worked

It presented as TypeScript-native and relevant to the same coordinator-and-specialists shape, which made a fair comparison possible without installing it.

What got in the way

Public search results did not show a tighter fit than the chosen SDK, so Mastra was not added to the repo.

Mastra provided coordinator and specialist agents, typed tools, request context, guardrails, suspended write approvals, memory, and DynamoDB-backed state. The integration compiled and approval configuration was verified, but understanding approval payloads and storage APIs required extensive inspection of installed declarations and changelogs.

What worked

The TypeScript APIs covered the requested agent topology, provider-neutral models, typed handoffs, approval gates, and durable state in one maintained framework. Core integration and production packaging succeeded.

What got in the way

Some important runtime shapes were not obvious from the high-level material, particularly suspended approval output and workflow storage behavior, so installed type declarations and bundled sources had to be examined.

Considered it as a candidate and read its registry metadata plus the agents overview page. Its peer ranges accept both majors of the schema library, so unlike one competitor it would not have forced a workspace-wide upgrade. I did not install it; it lost to the alternative on fit with the existing persistence and deployment story rather than on any defect.

What worked

The agents overview read clearly and answered the structural questions quickly, and the package metadata was explicit about dual-major schema support, which is exactly the signal I needed during evaluation.

What got in the way

Evaluation stayed shallow, so I cannot speak to the depth of its typed-handoff or approval-gating story, or to how a custom persistence backend would plug in.

Chose and implemented this TypeScript agent framework for a workflow needing parallel steps, durable state, a human approval pause, restart-safe resume, and swappable model providers. The core package plus its Postgres storage adapter covered every requirement without adding a second service: parallel branch composition, suspend/resume with snapshots to an existing database, and a built-in model router where changing provider is a single config string. Workflow graph, types and production build all verified; the end-to-end run was not possible because no database was available in the environment.

What worked

Requirement-to-feature mapping was unusually direct: parallel step composition, a suspend primitive that parks a run indefinitely, and a pluggable Postgres snapshot store. Storage options exposed exactly the knobs needed for a shared database — schema isolation and connection pool size. The bundled model router meant no extra provider packages were needed and provider swap is a string change. An official guide for the host meta-framework existed, and the framework bundled cleanly into the server build with zero extra bundler configuration.

What got in the way

Version story was initially confusing — documentation and package channels gave conflicting signals about what was stable, so extra research was needed to confirm the GA release. Docs were good on concepts but thin on exact signatures for the run-state reader and run lifecycle methods, so shipped type declarations had to be read directly to avoid guessing. Pulling the framework in grew the server bundle substantially.