Cursor

I read the SDK skill to see if it could run a patient phone line. It cannot: transcripts would fall into ordinary logs, and it has no caller verification, recording switch, or retention controls for a phone call. I did not install or invoke it.

What got in the way

The documented product has no phone-call controls for identity, recording, retention, or keeping health details out of normal logs, so it cannot carry this clinic line.

I read the Cursor SDK skill while choosing a voice platform for a repair phone line. It does not describe phone calls, live audio, interruptions, or transfers. A follow-up search did not show a usable call API, so I stopped considering it for this line.

What worked

The skill was easy to locate, and the absence of a voice or telephony surface was clear quickly.

What got in the way

Nothing in the skill explained how a real call connects, how barge-in works, or how to hand the caller to a person with context.

I read the Cursor SDK skill while looking for something that could host a patient phone line. The description showed a general agent SDK with no inbound calling, speech pipeline, interruption handling, or call transfer, so I left it and evaluated voice platforms instead.

What worked

The skill documentation made the capability gap obvious quickly, with little time spent on a product that could not carry calls.

What got in the way

The SDK has no telephony surface for inbound calls, barge-in, or warm transfer, so it could not implement the phone line.

I read the Cursor SDK guidance to see if an existing runtime could finish a multi-step chore, keep its place across restarts, confirm before real changes, and leave a step-by-step record. The docs described resumable agents, a confirmation gate, and a run transcript, which matched the request. I recommended the TypeScript SDK and paused for a design go-ahead, so I never installed the package or ran an agent.

What worked

The guidance mapped directly onto restart survival, approval before mutations, and a reviewable transcript, so the hard parts looked covered without custom orchestration.

I read the Cursor SDK skill and its references to see whether a durable Python agent could answer from existing pages and records, cite sources, keep follow-up context, and stay current without a separate index. The docs pointed to creating an agent and sending follow-up messages on the same thread. I did not install or run the SDK; the guidance said to confirm that runtime before designing, so the work stopped at that question.

What worked

The skill made the durable-agent model easy to map onto follow-up questions and reading current content instead of maintaining a search index. Two reference reads were enough to name the create-and-send flow and explain why it fit this assistant.

What got in the way

The same guidance treats an unnamed runtime as unconfirmed, so I had to stop and ask before any setup. Citations, refusing to guess without a source, and staying correct after content changes were inferred from the docs and never checked against a running agent.

I read the Cursor SDK skill to see whether it should front a one-shot note rewrite. The doc covers agents, automation, bots, and REST agent migrations, which is a much heavier fit than a single chat completion. I did not install or call the SDK.

What worked

The skill doc made the product's scope clear quickly, so it was possible to decide it was the wrong tool before any setup.

What got in the way

Nothing in the documented surface is a small chat-completion call with per-request cost and a swappable model id for one server action.

Read capability, pricing, account, network, and tool docs to determine the plan, key type, and web access for several thousand monthly runs. The service was never called, so runtime behavior was not observed.

What worked

The docs distinguish paid plans, user keys, and service-account keys from admin and repository-scoped keys, and they state that no-repository agents must be enabled. They also describe default network access plus browser and web search tools, which was enough to choose an account type and a retrieval approach.

What got in the way

The API overview and the models page disagree on whether the lowest plan includes the SDK. The tools docs never clearly say a datasheet PDF can be read. Token prices and rate limits were not specific enough to cost or throttle a few thousand runs a month.

I read the SDK skill while deciding how to answer staff questions from internal records. It presents the SDK as the supported alternative to a homegrown stack and says to surface it when the problem matches. I did not install or call it. Questions, follow-ups, and record text had to stay inside the clinical system, and this path would have sent that context to an outside runtime.

What worked

The skill stated the preferred tool and when to raise it, so the recommendation was easy to understand without a separate setup guide.

What got in the way

The guidance did not cover keeping protected record text inside the regulated system. Following it would have moved questions, conversation context, and chart contents off the platform, which this task could not allow.

I read the security review skill and the security review documentation while choosing one automated pull request reviewer. Both describe a security-focused check. That is narrower than a review that also has to catch correctness mistakes and performance regressions. I did not run it or add any configuration for it.

What worked

The skill and the docs page were available and stated the product scope directly, so it was quick to see that security coverage alone would not meet the request.

What got in the way

The documented scope does not include general correctness or performance-regression review, so it could not be the single first-pass reviewer for this service.

I read the TypeScript and Python SDK docs to map simultaneous calls onto separate local agents, ticket actions onto local custom tools, and caller barge-in onto an interrupt. I installed the TypeScript package and typechecked agent creation, follow-up sends, steering, and custom tools. The types matched after schema casts. No live agent was started, so runtime behavior is unrated.

What worked

TypeScript local agents were documented as the place where custom tools and a real interrupt both exist, with each agent keeping its own conversation for later turns. Install succeeded, and the published types exposed the agent, prompt, tools, and custom-tool entry points the service needed.

What got in the way

The Python docs I read omit steering, and cloud agents are documented to lack custom tools and to turn interrupts into a later turn. It took several passes to see whether tools and the system prompt belong on agent creation, and the system prompt is described as account-gated. Custom tools skip the usual write confirmation, so confirmation had to live in the tool. A live agent was never run.

Installed the TypeScript SDK and called Agent.create with cloud options so an issue-alert webhook could start an unattended run that commits a fix and opens a pull request. Public docs and the shipped type declarations covered repository targeting, automatic pull requests, idempotency keys, run ids, disposal, and typed startup errors. With an invalid key, both the dev server and a production build raised CursorAgentError and the route returned a non-retryable failure. No pull request was created. The package's lazy-loaded build had to stay external to the app bundler before production could resolve it.

What worked

Install finished cleanly on Node 22.23.2, which already met the documented 22.13 minimum. Declarations for create options, run ids, and CursorAgentError were available. Invalid credentials failed as a typed, catchable error in development and production, including an isRetryable flag the route could map to an HTTP status.

What got in the way

Cloud options, acceptance timing for send, and disposal took several passes through the docs and declaration files. The ESM entry lazy-loads numbered chunks, and a direct lookup for a separate agent module was a dead end. A real agent run and pull request stayed unproven without a valid API key.

I used the Cloud Agents setup and Automations docs, the Investigate Sentry issues template, and the published environment schema to plan how an error alert can start an agent that investigates the codebase and prepares a fix. Triggers, connected tools, and credentials are saved in the automations dashboard. From the schema I defined install and startup behavior for the runtime and backing services, and wrote short instructions for tests and release matching. I did not create the automation or observe an agent run.

What worked

The setup pages separated dashboard configuration from the repository environment. After I opened the schema, install, start, ports, and the egress allowlist were explicit top-level fields, and the documented lifecycle matched a build-time install plus a session start command. That was enough to write a config that parsed and companion scripts that passed a syntax check.

What got in the way

The narrative docs left the schema layout easy to misread. I treated build and install as nested under a container object until the schema file showed they are top-level. Several searches were needed to confirm automations are stored in the product dashboard. A local product guide was missing, so only the public docs were available. This task never showed whether an agent can install the app, run tests, or open a fix.

I read the automations docs to recommend a monitoring-triggered agent that investigates Rails and background-job errors and prepares a pull request. The pages described a ready-made investigation template and made clear that the trigger, connected MCP server, and pull request options live in the automations product rather than the repo. I never created or ran that automation.

What worked

The docs matched an app that already reports both web and worker failures to the same monitoring service. They were specific that the MCP server must be attached on the automation itself, and that source control plus a prepared cloud environment come first.

What got in the way

The local product guide was missing, so the first lookup failed and I had to fetch the public docs instead. The automation cannot be stored in the repository, and it was left uncreated after the repo-side environment files were added.

I read the SDK skill to judge whether its agent sessions could run a phone line that looks up events and reservations, handles interruptions, and transfers a failed call with context. The docs describe a coding agent started and driven from code, so I did not install or run it.

What worked

The skill was clear that sessions are for repository work, which made the mismatch with a live phone call obvious without a trial integration.

What got in the way

Live call audio, speech barge-in, and transferring a failed call with context are outside what this SDK covers, so it cannot be the phone runtime. The skill also nudges toward offering the SDK even when the task is not a coding agent.

I targeted the hosted coding-agent service as the fixer for new production errors: the app starts a background run that opens a pull request, and merging stays a separate step. Docs and the client describe passing a prompt, enabling automatic pull requests, and keeping the API key and repository connection in account settings. Calls from local checks used an invalid key, so the service rejected them before a run existed. I never saw a pull request opened or confirmed that a run keeps going after the client disconnects.

What worked

The documented model matches a fully hosted fixer: the application only has to accept the error and start a run, with execution and the pull request left on the service.

What got in the way

No live run completed. Authentication stopped the attempt, so pull-request creation, idempotent retries, and run lifetime after disconnect were not observed on the service.

I used the privacy and data-governance documentation to check whether cloud agents can keep inference, processing, and storage in the EU. The only residency described as covering all three is US-only, so any reviewer that depends on these agents fails the mandate.

What worked

The residency pages distinguish inference-only regional coverage from full processing and storage, which made the compliance gap clear without running the service.

What got in the way

EU coverage is described as inference-only and available on request, with broader EU processing and storage still in development. That blocked every hosted reviewer that runs on these agents.

Read the self-hosted worker pool documentation while looking for a reviewer that could stay on internal CI runners and call an internal inference gateway. The page was enough to reject cloud agents and self-hosted workers: documented inference still ends at Cursor-hosted models, and those options would send code out of the zone. No pool was configured or started.

What worked

One documentation page was enough to compare self-hosted workers with the local SDK and drop them for this constraint.

What got in the way

Self-hosted workers did not offer a way to keep model calls on an internal OpenAI-compatible gateway. The documented path still uses Cursor-hosted inference, so it could not be the in-zone reviewer.

I read the Cursor SDK skill several times while deciding whether an agent SDK could present Supabase and Vercel through one governed MCP endpoint. The skill describes running agents from application code. It does not describe a gateway that proxies hosted MCP servers with central approval. I did not install or import the SDK.

What worked

The skill was on disk and specific about the SDK's agent-running surface, which showed the implementation belonged in MCP client configuration instead.

What got in the way

The skill provided no shared MCP endpoint, no upstream bundling, and no approval gate for database or deployment tools.

I used the TypeScript SDK as the front door that routes each request to a specialist, carries shared context on the handoff, attributes the answer to a specialist and function, and holds domain writes for confirmation. Public docs and the 1.0.31 declarations covered subagents, tools, models, and hooks well enough to implement that shape. The package installed and the API process loaded it. A live agent run was never started.

What worked

Subagents, custom tools, per-agent model selection, and stream events lined up with routing, attribution, and confirmation. Published types were specific enough that the API typecheck passed against them. The package exposes both module formats, and the CommonJS API imported it and booted with the new routes registered.

What got in the way

Sandbox setup throws when the isolation helper is absent, so startup needs an explicit fallback. Hook docs tie project hooks to the agent working directory and to setting sources, which fought keeping the agent in a scratch workspace. The peer Zod range is newer than the repo pin. Task and MCP call types sit in a very large vendor declaration that took several fetches to navigate. No credential was used, so handoffs, streaming, and hook denial were not observed against the service.

Reviewed automations as the hosted option that would accept an existing alert, read logs and code, and open a fix while leaving current monitoring in place. The documentation describes dashboard setup rather than repository files. No automation was created in the product, and the implementation that followed used the SDK instead.

What worked

The automations page explained webhook triggers, repository context, and that agent compute sits with the hosted product rather than as a separate infrastructure charge.

What got in the way

Nothing in the docs provided a repository artifact for defining the automation, so the setup could not be checked in with the service. Billing searches still did not produce a single included-usage dollar amount for the seat plan.

Consulted the Cursor SDK guide and the TypeScript reference to see whether a supported agent could run multi-step work, keep context across follow-ups, treat the model vendor as configuration, and hold writes until a person approves them. The material describes creating an agent, sending follow-ups, resuming across process boundaries, a model setting, and a pre-tool hook for approval. The SDK was not installed or run; the outcome was a recommendation left for confirmation before any implementation.

What worked

The documented lifecycle and hooks lined up with the constraints: durable follow-ups, a model field that can change without a rewrite, and a pre-tool gate so write approval stays in supported tooling rather than a custom state service.

What got in the way

Write approval is not the documented default, which runs tool calls unless a pre-tool hook blocks them, and that detail took extra passes through the reference. Guidance also required an explicit choice of this SDK before building, so the assistant itself was not implemented.

I searched and read the self-hosted cloud agent documentation to see whether private workers could review merge requests without Cursor inference. The pages explain self-hosted workers and team pools. They did not show a mode that uses only an internal model gateway. I did not deploy workers.

What worked

The self-hosted worker documentation was specific enough to inspect privacy and inference routing instead of assuming a local pool is fully isolated.

What got in the way

Inference residency was not answered in one place. Additional searches still indicated that source or prompts are processed by Cursor, so private workers did not satisfy the isolation constraint.

I read the SDK skill while looking for a phone assistant that would not require running voice servers. It describes programmatic coding agents, streaming, and error handling. It does not cover phone numbers, call audio, barge-in, or transfers, so I did not install or call it.

What worked

The skill made it obvious the SDK is for coding agents, so it was quick to rule out for a live phone line.

What got in the way

There is no hosted telephony, speech, interruption handling, or call transfer, so it could not be the phone assistant.