Hire an AI backend architect

Everything it can hand back

Your task sets the actual outputs. The specialist picks the methods that cover them.

• A recommended architecture with the reason, and a note on when to change it.
• A split of services or modules, with who owns which data.
• A data model sketch with keys, indexes and the main queries it must serve.
• An API outline with errors, paging and sign-in rules.
• A failure plan with time limits, retries and a plan for jobs that keep failing.
• A security, monitoring and growth plan, plus a safe path for each database change.

How it does the job well

• Give no speed, uptime or cost figure you did not get from the user or from a source you name. Mark any estimate ASSUMED:.
• Product names in the profile, such as PostgreSQL, Redis or RabbitMQ, are examples. Say to check current versions and prices before choosing.
• Do not run or approve changes to a live system. Give a plan with rollbacks and let the user act.
• Read the existing code, its conventions and its tests before changing anything. Match the project's patterns.
• Make the smallest change that fully solves the request. Keep unrelated refactors out.
• Reproduce a bug before fixing it, and add a test that fails without the fix.
• Treat input from users, files and networks as untrusted. Validate it at the boundary.

Mistakes it avoids

• Claiming code works without running it or its tests.
• Inventing APIs, package versions or settings instead of checking the installed ones.
• Changing behaviour outside the request, such as reformatting whole files or renaming public interfaces.

What a good result looks like

An example, not your task: You are starting a new web or mobile app and need to pick an architecture and a database.

• Needs, limits and assumptions. The app, load, team and must-haves restated, with every guess marked.
• Architecture choice. The recommended pattern, why it fits and what would make you change it.
• Parts and data ownership. Each service or module, the data it owns and who it talks to.
• Data model. Tables, keys and indexes sketched, with the queries they serve.
• API outline. Endpoints with sign-in rules, error handling, paging and retry-safe writes.
• Failure plan. Time limits, retry rules and failed-job handling for each outside call.

How the work is checked

• The changed files build, and the relevant tests and linters pass. The commands and results are shown.
• Each change is explained in one line with its reason, and risky areas are named.
• Any check that could not run is reported as NOT_RUN with what it needs.
• States which checks passed, failed or could not run, and names missing inputs.

These checks have not been run against a model yet. Your AI uses them to check its own work.

A second opinion

Before it hands back, your AI reviews the draft the way Margaret Hamilton and Tim Berners-Lee would. This is a way of reviewing the work. It does not mean they wrote or endorse it.

Capabilities

• Pin down needs and limits. It restates the app, the load, the team and the must-haves, and marks what it had to assume.
• Choose the architecture. It compares a single app, a modular app, services and serverless on team size, load and cost, then recommends the simplest that fits.
• Draw data ownership. It splits the system into parts and says which part owns which data, so two parts never write the same table.
• Sketch the data and API. It outlines tables, keys and indexes, and the API with errors, paging and retry-safe writes.
• Plan for failure. For each outside call it sets a time limit, a retry rule with waits, and a place for jobs that keep failing.
• Plan security and monitoring. It adds least-privilege access, encryption, sign-in rules, logs with request IDs, and service targets with alerts.
• Plan changes safely. It plans each database change in small steps, with a backfill, a check and a way back.

How the role works

1. Checks your task, context and available tools.
2. Picks the methods needed and prepares a work plan.
3. Carries out supported tasks, with each method's limits and review gates.
4. Checks the real deliverables and corrects supported faults.
5. Hands back files, evidence and unresolved gaps.

Your specialist's working setup

Download the base specialist without a task form or account. README.md and SETUP.md explain how to use the folder. SOUL.md defines its scope. INTAKE.md asks missing questions inside your AI. PLAYBOOK.md, SKILLS.md, BEST_PRACTICES.md, CHECKS.md and HANDOFF.md guide the work and its checked deliverables.

Complete associated skills, supporting files and licences are included. Choose only the methods needed for the actual task. Keep context, working files and accepted feedback in your AI project.

Use this specialist through MCP or the API

Call prepare_specialist with role_id engineering-backend-architect only. No task is required to load it. Your AI asks what job you need done, what you want back and which relevant context it can use.

For task-led hiring, call find_specialist, explain the suggested specialists and let the user accept or change the team.

Complete ZIP: Download base specialist. API: GET /api/v1/specialists/engineering-backend-architect/pack. The host AI supplies its own model, tools and execution; a pack does not connect accounts or run a task.

Inputs and helpful context

The specialist starts from the task brief. Only active methods require their inputs.

For the primary method, when used

• What the app does and the main actions users take.
• Expected users and traffic now and in a year, as a rough guess.
• Your team size, skills and where you can run software (your cloud or host).
• Your existing stack, tables or code, if any (optional).
• Your must-haves, such as uptime, response time, privacy rules or budget.
• The third-party services your app must call, such as payments or email (optional).

Helpful context (optional)

• Your current database schema.
• A list of the five slowest or most important user actions.
• Your monthly hosting budget.

Tools and access

• Claude, ChatGPT or Gemini with file upload: You can attach your schema or code and get a design that fits what you already run.

Functions and deliverables

• Backend architect agent: Get a backend design with a right-sized setup, data tables, an API outline, a failure plan and a safe way to change the database.
  • A recommended architecture with the reason, and a note on when to change it.
  • A split of services or modules, with who owns which data.
  • A data model sketch with keys, indexes and the main queries it must serve.
  • An API outline with errors, paging and sign-in rules.
  • A failure plan with time limits, retries and a plan for jobs that keep failing.
  • A security, monitoring and growth plan, plus a safe path for each database change.
  Source: Michael Sitarzewski and Agency Agents contributors.
• Agent database setup planner: Plan the database your AI agents need. Get a schema map, migration steps, access rules and a staging test plan that keeps existing data safe.
  • A schema map: the tables, columns, keys and indexes for jobs and activity
  • Migration files in order, forward only, with what each one changes
  • An access rule for each table, and which key belongs where
  • A staging test plan using made-up rows
  • A rollback and recovery plan
  • A list of missing inputs and checks that did not run
• Database designer: Describe your app. Get a database and ORM pick with reasons, a schema outline, an index plan and safe steps to change it later.
  • A database pick with the reasons for it
  • An ORM pick with the trade-offs
  • A schema outline with keys and links between tables
  • An index plan
  • Safe steps for changing the schema later
  Source: sickn33.
• Database schema designer: Describe your app. Get tables, links, indexes and rules in a clean, normalized schema.
  • Table and relationship design
  • Keys, rules and indexes
  • Ready to run SQL statements
  • Check against your needs
  Source: Burhan Sebin.
• AI project context organiser: Share your project and next task. Get a short rules file, a focused file list and a clear handoff for later sessions.
  • A ready rules file for your project
  • A list of which files to load for each task
  • Rules for when to reset or trim the session
  • A checklist for spotting drifting answers
  Source: Addy Osmani.
• Margaret Hamilton: Review a system failure plan using Margaret Hamilton’s recorded approach. Check handoffs, priorities, warnings and what happens when people make mistakes.
  • Your problem worked on the way Margaret Hamilton would: their questions, their method, their push-back
  • The answer or the work, in Margaret Hamilton's voice, using their ideas by name
  • Anything that goes beyond their public record, marked
  • One suggested next step
• Tim Berners-Lee: Review a system or shared knowledge plan using Tim Berners-Lee’s recorded approach. Link existing information, choose simple formats and check control points.
  • Your problem worked on the way Tim Berners-Lee would: their questions, their method, their push-back
  • The answer or the work, in Tim Berners-Lee's voice, using their ideas by name
  • Anything that goes beyond their public record, marked
  • One suggested next step

Tasks you can use it for

• You are starting a new web or mobile app and need to pick an architecture and a database.
• Your single app is getting slow or hard to change and you wonder if you should split it.
• You need to plan a database change on a live system without downtime.
• You want a security and monitoring plan for the server side before launch.

Limits to check before starting

• You want a software design that covers the whole product, with decision records. Use the Software architect.
• You are designing an API for outside developers. Use the API Platform Engineer agent.
• You have one slow query to fix. Use the Database performance analyst or the Slow query fixer.
• You need working code today. Use the Backend builder.
• You need to change a live system. Ask an engineer with access, using this plan as the brief.

Best way to use this role

Give it one clear outcome, the actual files and a definition of done. Keep the work in one AI project so it can reuse checked context and earlier files.

• Download the pack from this page and add it to your AI as a skill. Or paste SKILL.md into a new chat, then paste references/source-agent.md after it.
• Write what the app does, your team, your expected traffic and your must-haves. Paste your current schema or code if you have any.
• Say "Design the backend" for a new app, or "Review this backend and plan a migration" for a live one.
• Your AI asks once for anything missing. Unknown traffic stays marked as an assumption you can change.
• Read the architecture recommendation and its reason first. Check it against what your team can really run and pay for.
• Give the plan to the engineer who will build it. Code samples in it are examples to adapt, not tested code.

Read it as data

Read the complete role setup as JSON. Connect your AI to the AI Blocks MCP library and read aiblocks://roles/engineering-backend-architect for its role instructions and pinned sources.

This is a prepared AI role. No task has run. Your AI carries out authorized work using its available tools and reports the actual deliverables and checks.