Gateway & reverse proxy
Use the request boundary to apply accepted contracts and resource policies before expensive application work. Document trusted headers, bypass paths, and where identity is established.
Review question: Who guarantees that the application cannot be reached through an unreviewed alternate route?
Explore the pattern ↗Identity & delegated access
Carry verified caller context into application decisions. Avoid trusting user-supplied tenant identifiers as the source of authority. Distinguish the human user from a service or agent executor.
Review question: Where is the relationship between caller, tenant, resource, and action verified?
Explore the pattern ↗Services & background workers
Apply resource checks to synchronous operations, exports, queued tasks, and nested objects. Review changes in membership or ownership between proposal and execution.
Review question: Does the worker revalidate the relevant permission before performing the action?
Explore the pattern ↗Logs, metrics & traces
Connect operations across components while separating aggregates from restricted investigation events. Track delivery failures and missing usage as part of the system state.
Review question: Can the team tell the difference between no activity and no telemetry?
Explore the pattern ↗Model calls & tool executors
Treat generated tool arguments as proposals. Apply execution-time scopes, resource permissions, and relevant approvals. Keep untrusted content away from authority to execute.
Review question: Which independent check still protects the resource when the model is wrong?
Explore the pattern ↗Budgets & consumption records
Coordinate reservations across concurrent work and reconcile reported usage after the call. Give incomplete outcomes an explicit state instead of assuming zero consumption.
Review question: What happens after cancellation, duplicate completion, or a missing provider usage report?
Explore the pattern ↗Write the handoff contract.
For each connection, record the input contract, accepted identity context, enforcing component, error behavior, evidence fields, and responsible owner. Review the data allowed to leave the boundary and the permissions granted to the receiving service. A diagram is useful only when the implementation respects the responsibilities it shows.
Test a representative allowed operation, an unauthorized operation, a missing dependency, and a delayed outcome. Keep provider-specific settings in version-controlled implementation documentation. Names and capabilities can change; validate the components actually running in your environment.