Backend Engineer agent

The Backend Engineer agent implements server-side changes. It works from an approved design and describes the change: the files it touches, the key code, and the impact on APIs.

Where it runs

Feature SDLC is the longest built-in workflow, with eight steps: requirements, delivery plan, technical design, backend, frontend, end-to-end tests, security review and user docs. The Backend Engineer is step four. It comes right after the Architect's technical design and before the Frontend Engineer.

Inputs

• The session task.
• A read-only snapshot of relevant files from the project's repository: routes, services, data models and existing tests.
• The earlier steps: requirements from the Product Analyst, the delivery plan and the technical design. In an eight-step workflow these reach it in shortened form.

Outputs

A description of the server-side change, per file, with:

• New and changed endpoints, and whether any change breaks existing callers.
• Data model changes, which the design should already have named.
• Error handling and validation.

The Frontend Engineer builds against the API it describes. After all eight steps, the session's code pass writes the files into a throwaway copy of the repository, the project's tests run against that diff, and the findings pass reviews it.

Example run

Illustrative example, not a recorded session. For a feature that lets customers save filter presets, the Backend Engineer proposes a presets table owned by the user and the workspace, three endpoints to list, create and delete presets, and a limit of 20 presets per user with a clear error past it. It notes that listing must be scoped to the caller's workspace and that deleting someone else's preset must return not-found rather than forbidden. The Frontend Engineer then plans the UI against those endpoints.

Limits

• It does not run a server, a database or migrations. It describes code.
• The code pass reads a fixed amount of the team's output. In Feature SDLC, with eight long steps, parts of later steps can fall outside what it reads. Check the diff covers what was planned.
• Breaking API changes are reported in text. Nothing enforces versioning unless your tests do. See quality gates.