CARE: The Framework A-Teams Uses to Ship Production AI Software

The uncomfortable truth about AI-assisted development

Most teams building with AI right now are running on luck.

The tools are astonishing. Claude Code writes real production modules. Cowork drafts full documents. MCP servers plug agents into databases and ticketing systems. A single developer can now ship what a small team used to.

But watch what happens after a few months:

• A new dev joins and asks “why do we do it this way?” — nobody remembers.
• A model provider updates their SDK and half the prompts start returning subtly different shapes.
• A regulator asks for a decision trail and the team spends a week reconstructing it from Slack.
• A dev leaves and takes the mental model of the project with them.
• The AI ships a working endpoint with no auth guard, and no one catches it in review because “the tests are green.”

None of these are the AI’s fault. They are the absence of a framework.

We spent the last year building one. We call it CARE. It is now A-Teams Soft Solutions’ company-wide standard for AI-assisted software development. This post explains what it is, why it works, and how you might steal ideas from it for your own team.

Why generic best practices don’t cut it

There is no shortage of “best practices for coding with AI” content online. Most of it is written for individual developers. It assumes one project, one codebase, one dev, one preferred model.

Real-world software work is not that. At A-Teams, a typical engagement has:

• Multiple developers, each with their own AI tool preference — one lives in Cowork, another in Claude Code, a third in Cursor.
• A regulated domain — healthcare, finance, government — where “we tried our best” is not a defence.
• Multiple jurisdictions — the same platform touching GDPR, KSA PDPL, DPDP India and UAE PDPL simultaneously.
• A model landscape that changes every quarter — the default model six months ago is not the default today.
• A client who does not want to hear “sorry, the AI forgot”.

Generic best practices cover none of these consistently. They fix moment-to-moment behaviour. They do not fix the project’s memory, its guardrails, its compliance posture, or its ability to survive a lead going on holiday.

CARE was built to fix all of those at once — and to keep working when the model, the tool, the developer, or the jurisdiction changes underneath it.

What CARE actually stands for

Four pillars:

• Context-driven — every AI session starts from the project’s own reference files, not from whatever the model happens to remember.
• AI-Guarded — every model call sits behind named, mandatory guardrails.
• Reference-based — decisions, prompts, schemas, incidents are written down once, in a known file, and read by everyone (humans and AI).
• Evidence-backed — quality is proven by tests, evals, audit logs and gap analyses. Not by claims.

The one-line summary: CARE externalises everything the project knows about itself into versioned Markdown files inside the repository, and treats those files as the source of truth for every AI tool that touches the project.

That single decision — writing things down externally, instead of relying on the AI’s context memory — solves most of the problems above.

The .md reference system

CARE ships as a set of drop-in Markdown templates. Every A-Teams project copies them into its repo on day one and fills in the blanks.

The core files:

Each file has a named owner (project lead, security lead, AI lead, etc.) declared inside the file itself. Changes ship as PRs. Some files are append-only — handoff.md, decisions.md, incident_log.md, prompt_log.md — because their history is their value.

Why Markdown, not a wiki or Confluence? Two reasons. First, the files version with the code — the moment the codebase changes, the docs change in the same PR. Second, every AI tool can read them. Cowork, Claude Code, Cursor, a custom MCP client — all can be pointed at a file path and told “read this before you do anything else.”

The eight hard rules

These are the floor of the framework. Blocking gates, not suggestions. A PR that violates one does not merge.

1. No real production data in prompts. Synthetic or anonymised seed data only.
2. All write endpoints pass through the project’s auth + RBAC pattern.
3. All AI-generated code is human-reviewed before merge.
4. No new external dependency without an entry in decisions.md.
5. No schema change without updating architecture.md and shipping a migration.
6. No production prompt without registration in prompt_log.md.
7. Context window discipline: 50% used → warn, 75% → prepare handoff, 90% → mandatory handoff.
8. Compliance gates listed in compliance.md are blocking, not advisory.

Rule 7 is the one that surprises people. Large-context models silently degrade long before they hit the hard limit — the “lost in the middle” effect. By the time you notice, the AI has forgotten a security rule you stated in the second message. Enforcing a 50/75/90 protocol turns “the AI is being weird” into “we hit 82%, hand off now.”

The rules are dry, but they are what makes quality reproducible instead of accidental. Every lead memorises them. CI enforces the ones a machine can check.

Named guardrail patterns

CARE gives every guardrail a name. Named guardrails become code-review checklist items instead of vibes.

• PIIScrub — server-side utility that removes T2/T3 identifiers before any payload reaches a model. Wired at every LLM call site. A CI lint fails the build if any call site is missing it.
• PromptEnvelope — the convention for wrapping prompts with explicit delimiters and instruction hierarchy, so the model treats user input as data, not as commands.
• OutputContract — schema validation applied to every model response. Free-form text is a security risk when downstream code reads it as a control signal.
• GuardedRoute — the auth + RBAC decorator applied to every route handler. AI omits guards on “simple” endpoints; a named pattern makes “is this present?” a yes/no review question.
• AuditLog — the structured emitter that records who did what, when, from where. Never captures raw sensitive data.
• RateLimit and CostBudget — per-user, per-tenant, per-feature caps that defeat denial-of-wallet attacks and runaway AI costs.

The value of naming is enforcement. When a lead tells the AI “apply the GuardedRoute pattern + PIIScrub on input + OutputContract on response,” the AI’s output is checkable in seconds — not debatable across an hour of PR comments.

The compliance module — industry-agnostic and pluggable

CARE itself does not assume a domain. compliance.md carries a regime matrix where the project ticks what applies:

• GDPR, UK GDPR, HIPAA, CCPA, DPDP, KSA PDPL, UAE PDPL, DHA/DoH/NABIDH/Malaffi, NPHIES, PCI-DSS, SOC 2, ISO 27001, LGPD, PIPEDA, plus an “Other” row.

Each ticked regime triggers a controls block: lawful basis, retention, residency, breach notification window, AI-specific controls (can prompts carry personal data, can the provider train on it, what region does inference run in, is there a no-train clause in the contract).

On top of the regime-specific controls, CARE enforces eight universal AI compliance gates on every project regardless of jurisdiction:

1. PII/PHI scrubber on every prompt.
2. Structured output validator, not free text.
3. Audit log with prompt/response hashes — never raw content.
4. Region pinning matching the input’s data tier.
5. No-train contract clause with the provider.
6. Human-in-the-loop for irreversible actions.
7. Retention matching the shortest applicable period.
8. User-erasure requests purge AI logs too.

A failed gate fails the build.

What this looks like in production

Three brief examples from A-Teams engagements.

1. Healthcare rostering (NurseRoster AI)

A hospital rostering platform needed AI-suggested shift assignments. The developer read of the brief was “build a Bedrock endpoint that suggests nurses for shifts.”

The product-owner read, once CARE was applied, was different. The user was a ward admin — usually a nurse manager, not technical. Their job to be done was to fill 30 shifts in under 30 minutes each week. Their friction today was three hours of spreadsheets and phone calls. The business value was clear. But the acceptance criteria mattered most: 90% of AI suggestions should require zero human edits, and every suggestion had to include an explanation the admin could defend to their team.

That last requirement changed the design. The OutputContract for the endpoint enforced an explanation field with structured reasons (license expiry, hours, unit skill match). The prompt was registered in prompt_log.md with a golden eval set derived from historical rosters. PIIScrub stripped Emirates ID and staff names before any Bedrock call. The endpoint shipped; three months in, it holds its 90% acceptance rate.

Without CARE, this would have shipped as a functional but un-defensible endpoint. The nurse manager would have hesitated to use it because “the AI said so” is not enough when your team asks why they got a night shift.

2. KSA hospital after-hours booking

A hospital in Saudi Arabia wanted an AI agent to handle after-hours calls: booking, rescheduling, cancellation. The developer instinct was “add a chatbot; support Arabic and English.”

The product-owner analysis surfaced the real complexity. About 10% of after-hours calls were about emergencies, not bookings. Missing an emergency was catastrophic; missing a booking was annoying. The failure cost was asymmetric — designs must optimise for the worst case. On top of that, KSA cultural rules ruled out certain tone patterns, and the agent had to refuse any medical advice explicitly.

compliance.md flagged KSA PDPL and cultural norms. The prompt (registered in prompt_log.md) included refusal-taxonomy few-shots, a strict scope of “booking + escalate,” and an escalation path tested weekly with synthetic emergency prompts. The AuditLog recorded every interaction. Human review triggered on any conversation the agent could not confidently place.

The launch was uneventful. Which was the point.

3. The cost spike that wasn’t a downgrade

AI bills doubled overnight on one project. The developer instinct is always the same: switch to a cheaper model.

The CARE-aligned response was slower. First, check the SLA the client bought — a downgrade may breach it. Second, look at prompt_log.md and the cost dashboard to identify which prompt spiked. Third, check whether prompt caching was off for a heavy shared prefix. Fourth, check if one user or tenant was making unusual volume — a denial-of-wallet vector. Fifth, run the math: are you saving £X but losing £Y in downstream quality regression?

The fix was rate-limit + cache + alert + tier customers — not a blanket downgrade. It took two hours instead of thirty minutes and it did not create a quality regression that would have cost the client relationship. The decision was recorded in decisions.md as an ADR, so the next on-call knows what was tried.

The productivity math (multi-lead angle)

The most surprising outcome of CARE has been what happens when multiple leads work the same project.

Without a framework, two leads on one project typically ship at ~1.4× one lead’s pace — not 2×. The gap is spent on merge conflicts, contradictory decisions, and re-discovering each other’s context. Two leads on two separate projects are usually more productive than two leads on one shared project.

With CARE’s collaboration rules — module ownership, file ownership routing, shared prompt library, cross-handoff protocol, weekly close — three leads on one project ship at approximately 2.5× one solo lead. The coordination overhead is roughly 30 minutes per lead per day. It pays for itself in the first sprint and compounds after that.

The mechanism is not magic. It is the removal of contention:

• Named module ownership removes ~80% of merge and decision conflicts.
• A shared, registered prompt library halves prompt engineering cost on second use and near-zero after that.
• Cross-handoffs turn handover idle time into productive parallel time.
• Pair sessions on high-stakes changes prevent incidents that would otherwise consume 1–3 days each.

Adopting CARE in 90 days

You don’t need permission from anyone to start. The framework scales down — a solo dev on a small project fills in less detail, but the templates are the same.

Week 1 — Drop the .md template pack into the repo. Fill CLAUDE.md, compliance.md regime matrix, data_classification.md for the most sensitive entities. Wire the three highest-value CI gates (PIIScrub, OutputContract, GuardedRoute lint). Run a first gap_analysis.md.

Weeks 2–3 — Backfill architecture.md and per-module files. Register existing production prompts in prompt_log.md. Retro-fit incident_log.md from recent post-mortems. Start the daily handoff habit.

Weeks 4–5 — Wire the remaining CI gates listed in compliance.md §4 and security.md §6. Assign owners for every .md file with named humans, not roles. Add the two-reviewer rule for high-stakes PRs.

Weeks 6–8 — Run your first formal end-of-sprint gap analysis. Review incident_log.md for patterns. Update CLAUDE.md with any rules that surfaced.

Weeks 9–12 — Run the first quarterly review of compliance.md, security.md, and tool_policy.md. Have the team score themselves on the CARE assessment. Identify gaps for training. Ship the next release with all gates green.

At the end of 90 days, you will have a project that survives a lead going on holiday, a model provider changing their SDK, a regulator asking for an audit trail, and a client asking “how do you ensure quality?” — all without the sinking feeling of “let me get back to you.”

The bigger point

Code is increasingly a commodity. Any competent developer with modern AI tooling can produce working software fast.

What is not commoditised — and won’t be — is judgment. Deciding what to build. Naming the right guardrails. Knowing which trade-off to accept and which to record. Communicating that trade-off up to the client so trust survives. Ensuring the team that comes after you can pick up where you left off, whether they arrive tomorrow or in eighteen months.

CARE is our attempt to make judgment reproducible. To externalise it. To version it. To let it survive the model change, the tool change, the team change.

We built it because the alternative — running on luck — is not something A-Teams was willing to keep doing.

The CARE framework is A-Teams Soft Solutions’ internal standard. If you’d like to see the full template pack or talk about applying similar ideas to your own team, get in touch — we’re happy to share what we’ve learned.