Step 5 — Apply AI Recommendations
After a simulation run, select Get AI Recommendations to analyse the current architecture and simulation results. The engine returns a prioritised, categorised set of findings.
Recommendation categories
| Category | What it addresses |
|---|---|
| add service | Missing services that would materially improve performance, resilience, or cost |
| architecture | Structural changes — async decoupling, circuit breakers, retry patterns, fan-out |
| modify config | Configuration adjustments on existing services — concurrency, caching, timeouts, memory |
| scaling | Auto-scaling configuration gaps |
Severity interpretation
⚠️ WARNING — address before deployment. These findings represent real failure risks or significant cost inefficiencies at the simulated load. Examples: Lambda throttling at target RPS, API Gateway as a single point of failure, missing CloudFront for a high-read API.
ℹ️ INFO — improvement opportunities that are not blocking but should be considered for production workloads. Examples: Lambda provisioned concurrency, DynamoDB on-demand mode, SQS visibility timeout tuning.
Work through WARNING items first. A common initial pattern for a Lambda-based API architecture is:
- Add CloudFront (WARNING) — reduces API Gateway load and latency at edge
- Enable Lambda Provisioned Concurrency (INFO) — eliminates cold starts under spike load
- Introduce Circuit Breaker (WARNING) — prevents Lambda cascade failures when downstream services degrade
- Implement SQS async processing (INFO) — decouples write path to protect downstream databases
- Configure Auto Scaling (INFO) — ensures concurrency limits grow with load
Applying recommendations
Each recommendation can be expanded to read the full rationale before accepting. When accepted:
- New services are added to the canvas automatically
- New connections are wired according to the recommended topology
- Configuration changes are applied to the relevant node
After applying recommendations, re-run the simulation before accepting the next batch. This confirms the change had the expected effect on latency, cost, and health — and may reveal new recommendations that were not visible in the previous state.
Recommendation best practices
- Do not accept all recommendations in a single batch. Apply WARNING items, re-simulate, then review INFO items in the new state.
- Read the rationale before accepting. Recommendations are contextual to your architecture — understanding why a change is being proposed helps you assess whether the trade-off is appropriate for your use case.
- Use Refresh Recommendations after significant canvas changes to ensure the engine is analysing the current state.
- Dismiss irrelevant recommendations explicitly. This keeps your recommendation history accurate and ensures future sets are relevant.
- API Gateway throttling that persists after other fixes requires a specific response — see Pattern 6.