learntodriveai.dev/Cloud Engineering/Designing a Complete AI Practice Infrastructure
Cloud Engineering·Project 23·8 units

Designing a Complete AI Practice Infrastructure

**Track:** cloud-engineering

§ Brief

You're designing the complete AI practice infrastructure — project memory, tool connectivity, skills, and hooks — for the 15-engineer cloud team at Harmoni Insurance, a regulated insurer in Kuala Lumpur.

What you're practicing: AI infrastructure as a designed system, not a folder of files — a project memory layer authored from a blank repository, a connectivity decision made on its costs, single-purpose skills in the standard format, and a hooks layer that turns a regulatory rule into a control that always fires. A portability layer (AGENTS.md alongside CLAUDE.md, standard SKILL.md skills, hook patterns documented for reimplementation) so the work survives the team adding a second tool. A verification architecture arranged by stakes — a staging tweak verified lightly, a policyholder-data change verified hard — with a named-engineer, named-approval accountability chain built in. The AWS footprint is almost nothing; the substance is the infrastructure and the judgment behind it.

What you're learning about the loop: at the summit the failure mode flips. Until now the work was adding the right mechanism. Here AI's bias is the foil — it connects every MCP server it can name because more capability looks complete, writes one giant context file because that's easiest, delegates the architecture and the security policy because delegation looks like speed, and reviews a trivial change and a regulated one with the same depth because it has no model of stakes. The most useful work you do is the negative work: deciding when NOT to connect, when NOT to delegate, and proving each restraint to an expert client who will ask what you're missing.

Your Role

After this project you can design a team's whole AI practice infrastructure from a blank repository, defend each connection and each delegation boundary as a deliberate decision, make a regulatory requirement deterministic rather than advisory, and build the portable layer that keeps the knowledge alive after a tool switch and after you leave. You run a full discovery, design from the constraints you surface, and document the architecture so the next owner can run it.

The client is an expert. She has used Claude Code, Cursor, and Copilot and designed verification workflows before. She will not be taught what a hook is — she is asking you to design the system for a team where inconsistency is a regulatory risk, not just an efficiency one. Almost nothing is provided. The AI relationship is not part of the deliverable here; it is the deliverable.

What's New

Last time, at ĂnNhanh in Vietnam, you designed a deployment architecture: a shared CI/CD platform eight teams had to choose to adopt, a canary with automatic rollback, and a deliberate silent-failure proof — and you chose, per rule, whether memory, a skill, or a hook should encode it.

This time the AI directing relationship reaches its summit. Last project made which mechanism encodes which rule a decision. This one reverses the scale: you design the entire mechanism set — memory, connectivity, skills, hooks — for a whole team, from nothing. There is no carried-forward CLAUDE.md to extend. The client communicates in formal, structured kickoff notes rather than a fast Slack thread, and a regulator's accountability chain becomes a load-bearing constraint that reshapes the hook design.

The hard part: the natural answer is the wrong one almost everywhere. Connecting every tool, centralizing all context, delegating the hard decisions, and verifying everything the same way each feel like progress. Catching AI doing the reasonable-but-wrong thing — and saying why each "no" is correct to someone who will push back — is the work.

Tools

  • Claude Code — the primary AI tool the infrastructure is built for; everything you author governs how AI behaves for the team.
  • Cursor — named as the second tool the portability layer must serve. Referenced, not driven from.
  • Git / GitHub — the AI infrastructure is version-controlled, and commit traceability is the spine of the regulatory accountability chain.
  • An MCP server — a read-only AWS / infrastructure connection you scope, and decide whether to connect at all.
  • Terraform — a small footprint: the budget-alarm stack and one tiny demonstration target for verification calibration.
  • AWS CLI — the demonstration target's resources and the orphan scan at teardown.
  • AWS Budgets — the budget guardrail, provisioned first.

Materials

In the project zip:

  • Kickoff notes (kickoff-notes.md) — the engagement-opening artifact. Formal and structured. What it does not pin down surfaces only in discovery.
  • Regulatory-context sheet (regulatory-context.md) — the Bank Negara Malaysia traceability requirement in plain terms. It states the constraint and offers no solution.
  • Repo skeleton (repo-skeleton/) — a blank repository with only the budget-alarm Terraform stack and an empty docs/ directory. No CLAUDE.md, no AGENTS.md, no skills, no hooks.

There is no memory, skill, hook, or verification template. The whole infrastructure comes from the conversation and the constraints. The budget-alarm-first habit and the orphan-scan teardown discipline carry forward unchanged.