Deep Dive - Agent Backend & SCM Integrations

The agent backend is the surface Cursor lives or dies on. An Engineering Manager, Core Services who treats it as plumbing will lose the room - treat it as the product, because it is.

A single agent run is not a request. It is a long-running, stateful session that may take seconds or minutes, calls an LLM many times, touches the user's files and SCM and streams partial results the whole way. Modeling that as synchronous request/response is the first mistake an interviewer will probe for.

The shape you want is a durable workflow: accept the run, persist its intent, drive it forward through a queue and stream progress out of band. If the box handling step 7 dies, step 8 should resume from durable state somewhere else.

Why request/response breaksthe wrong default

The orchestration spinewhat you'd whiteboard

Decompose the run into steps, persist each transition and let workers pull work. This is the table to draw when the interviewer says "design the agent backend."

Partial failure and resumptionthe senior-signal point

A transient model timeout on step 6 of a 10-step run must not restart from step 1. Checkpoint after each step, make each step idempotent so a retry can't double-apply an edit and key external side effects so re-running is safe.

• Checkpoint progress after every step so recovery resumes mid-run, not from zero.
• Make steps idempotent - a retried tool call or file write must converge to the same result, never duplicate it.
• Distinguish retryable (timeout, 429) from terminal (bad request, auth failure) errors and route them differently.
• Cap total cost and step count per run so a confused agent loops into a guardrail, not a budget.

Streaming and backpressurethe editor is watching

Users expect tokens to appear as the model produces them. That means a long-lived connection per active run and a plan for when the consumer is slower than the producer. If the client can't keep up, buffer with a bound and shed or pause rather than blowing memory on the server.

The job description names it directly: build resilient abstractions over source-control providers. The skill being tested is whether you can hide GitHub's, GitLab's and Bitbucket's quirks behind one interface the rest of Cursor can trust.

Product surfaces should ask for "the diff for this PR" or "open a pull request," not learn that GitHub paginates with a Link header while GitLab uses X-Next-Page or that one returns 403 for rate limits and the other 429. The abstraction is where that knowledge lives and dies.

The clean interfaceone contract, many backends

Define a provider-neutral interface - repos, refs, diffs, PRs, comments, webhooks - and implement an adapter per provider behind it. Normalize the data model so product code never branches on which provider it's talking to.

interface ScmProvider {
  getPullRequest(repo: RepoRef, number: number): Promise<PullRequest>;
  listChangedFiles(pr: PullRequestRef): AsyncIterable<ChangedFile>; // hides pagination
  createReviewComment(pr: PullRequestRef, c: NewComment): Promise<Comment>;
  verifyWebhook(headers: Headers, body: Buffer): WebhookEvent; // hides per-provider signing
}

// GithubAdapter, GitlabAdapter, BitbucketAdapter implement this.
// Rate-limit, pagination and retry logic live inside each adapter, never above it.

Rate limits and paginationthe two things candidates get wrong

GitHub gives you a primary hourly budget plus an opaque secondary rate limit that punishes bursts and concurrency. Respect both. Read the limit headers, throttle proactively with a token bucket and back off when told to.

Graceful degradationtheir outage is not your outage

GitHub has bad days. When a provider degrades, the rest of Cursor should keep working. Reads fall back to cache; writes get queued and replayed; only the directly affected feature shows a soft failure.

• Cache reads (repo metadata, recent diffs) with a TTL so a provider blip serves slightly stale instead of nothing.
• Queue writes (comments, PR creation) and replay them when the provider recovers, with idempotency so replays don't duplicate.
• Wrap each provider in a circuit breaker so a hung GitHub doesn't exhaust your connection pool and starve unrelated features.
• Show a scoped, honest degraded state in the UI rather than a generic crash.

Inbound webhooks and API driftthe integration is two-directional

Providers also push events to you - PR opened, push, comment. Treat that ingress like any untrusted, at-least-once stream: verify the signature, dedupe on the delivery id and tolerate replays and out-of-order arrival. Separately, providers change their APIs without asking. The adapter layer is the firewall that absorbs that churn so no product team has to.

Core Services sits between every product surface and the infrastructure underneath. The contracts you draw there are impact: a good one unblocks every product team at once, a leaky one creates coordination tax forever.

The JD calls for "clean abstractions, well-defined service contracts." In the interview that means you can name what each service promises, version those promises without breaking callers and defend where you drew each line.

What a contract actually specifiesbeyond the function signature

A contract is more than an API shape. It states the guarantees a caller can build on, so product teams can reason about your service without reading its code.

Versioning and backward compatibilityyou cannot break product teams

Shared infra changes constantly while its callers can't all redeploy in lockstep. The discipline is additive change: add fields and endpoints, never repurpose or remove them under a live contract. When a breaking change is unavoidable, run both versions and migrate callers off the old one before you retire it.

• Make changes additive by default - new optional fields, new endpoints - so old callers keep working untouched.
• Run contract tests in CI on both sides so a breaking change to the auth or webhook service fails the build, not production.
• For unavoidable breaks, version explicitly, dual-run, migrate callers, then deprecate on a published timeline.
• Treat the contract as the artifact you review most carefully, because it has the widest blast radiusHow much breaks if a change goes wrong; the scope of potential damage..

Build vs buya judgment call you must defend

Auth, queues and SCM access each have credible buy options. The interviewer wants your reasoning, not a dogma. Decide on reliability, cost and control and be honest about the cost of owning a thing forever.

Auth, webhooks, the agent backend and SCM all run for a tool with over a million daily developers. Reliability here is not a quality of the system - it is the personal responsibility the JD assigns to this role.

The mature way to talk about reliability is in budgets, not absolutes. You don't promise five nines on everything; you set a target per service and spend the remaining error budget on velocity. That framing alone reads as senior.

SLOs, SLIs and error budgetsthe vocabulary that signals seniority

Containing failureblast-radius discipline

One failing dependency must not take the product with it. Circuit breakers, timeouts and bulkheads keep a slow SCM provider or a degraded model from cascading into auth or the editor.

• Circuit breakers around every external dependency, so a hung provider fails fast instead of consuming the thread pool.
• Aggressive timeouts plus bounded retries with backoff and jitter - retries without jitter synchronize into a thundering herd.
• Bulkheads: isolate resource pools per dependency so one saturated integration can't starve the others.
• Graceful degradation paths defined per feature, so the answer to "GitHub is down" is a known reduced mode, not a guess.

Always-on and burstythe two scale realities here

Auth and the agent backend can't take maintenance windows - a developer in another timezone is always working. That pushes toward multi-region and tested failover. The agent load is also spiky, so capacity planning has to target the burst, not the daily average.

Here is the prompt to rehearse cold: design the pipeline that authenticates a user, calls SCM, runs the agent and emits a webhook on completion. It forces all four domains into one diagram with clean contracts between them.

This is close to what the paid onsite working session actually feels like - a real system, built with the team, no AI assistance beyond autocomplete. The artifact you want in your head is the data flow plus the failure mode at every hop.

The end-to-end flownarrate it as steps

1. 1Authenticate. The intake API validates the user's token (OAuth/OIDCOpenID Connect. A modern standard that powers single sign-on, built on OAuth.), checks RBACRole-Based Access Control. Granting permissions by role rather than configuring each person individually. for the repo and action and rejects fast on failure. Auth is on the hot path, so it must be cheap and cached.
2. 2Accept and persist. Write a run record to durable state, return a run id immediately and enqueue the first step. The user is now unblocked while work proceeds asynchronously.
3. 3Call SCM. Through the provider-neutral abstraction, fetch the repo context - branch, diff, files - with caching, pagination and rate-limit handling hidden inside the adapter.
4. 4Run the agent. Workers drive the run step by step, calling the model, checkpointing after each step, streaming tokens to the editor and enforcing cost and step caps.
5. 5Emit completion. On finish, publish to the webhook service with at-least-once delivery, retries with backoff and jitter, signing and a dead-letter queue for the deliveries that never succeed.

How the contracts composefour services, clean seams

Failure modes and blast radiusname them before you're asked

Quantify itnumbers make the design real

Reach for order-of-magnitude figures and the levers behind them, framed as your targets rather than Cursor's published numbers.

The management anglewhere most engineers stop and you shouldn't

This is an EM loop, so end on people, not boxes. How would you staff, sequence and de-risk building this with a small, high-talent-density team in a flat org?

• Sequence by risk: harden auth and the durable state spine first, since everything else depends on them.
• Ship a thin vertical slice end-to-end early - one provider, one agent step, one webhook - then deepen, so integration risk surfaces in week two not month three.
• Staff to ownership, not layers: a small team where engineers own a domain end to end fits Cursor's "no narrow job descriptions" culture better than a handoff chain.
• De-risk with contract tests and a staging game-day before the first real load and stay hands-on in the reviews yourself - this is a player-coach role.