Aidan Marshall

I passed the Google Cloud Associate Cloud Engineer certification after completing a rigorous six-week Google Cloud cohort for partners, with hands-on labs, technical reviews, and practical infrastructure work throughout the program.

As organizations increasingly operate across platforms, staying multi-cloud ready matters—not to force one solution everywhere, but to understand the strengths of each cloud and choose the right approach for the problem.

For roughly 30 minutes, a Pokémon card drop appeared to overwhelm major parts of the Sam's Club website. Product pages stopped loading, login systems failed, sessions broke, and even unrelated parts of the shopping experience appeared degraded. I cannot say what specifically caused the outage, but watching it happen was a useful reminder: the age of AI does not make traditional systems engineering less important. It makes it more important.

AI has lowered the barrier to building software that is persistent, adaptive, capable of navigating changing pages, able to retry intelligently, and able to run across many products and retailers. Infrastructure may need to handle thousands of automated clients reacting simultaneously, refreshing sessions, retrying requests, and competing for the same inventory.

The hard questions remain deeply rooted in systems engineering: isolate failures, protect authentication from traffic spikes, prevent retries from amplifying an outage, degrade gracefully, and separate legitimate customers from abusive automation without blocking both.

AI is creating more capable software participants. The systems underneath them still need queues, rate limits, circuit breakers, observability, capacity planning, and thoughtful failure isolation. The future may be agentic, but it will still run on distributed systems—and those systems will be tested harder than ever.

I earned the GitHub Certified: Agentic AI Developer (GH-600) certification after taking the exam during its beta period, when there were no official practice exams, very limited community guidance, and a months-long wait while Microsoft and GitHub validated the exam before general availability.

The biggest takeaway was how quickly software engineering is evolving from writing code toward designing, governing, and collaborating with AI agents throughout the software-development lifecycle. GitHub Copilot, agent workflows, MCP, GitHub Actions, orchestration, governance, and human-in-the-loop development are becoming core engineering skills.

As my teammates and I continue building a large multi-agent system and adding new participants, a recurring question arises: should we allow this agent to operate in production?

Consider an agent capable of changing the status of work in a mission-critical tax system and another capable of messaging leadership when a task is complete. Each capability may seem reasonable alone. Combined, the system could incorrectly update the system, interpret that update as successful, and immediately communicate incorrect information.

Before production, we need to ask what actions the agent can take, how reversible they are, what downstream agents or tools it can trigger, what evidence is required before it proceeds, and when a human should be involved.

Autonomy cannot be granted once at the agent level and forgotten. It must be evaluated across the full chain of actions, dependencies, and consequences. The critical question is not simply whether we trust an agent, but whether we trust that agent, with those tools, in that workflow, under those conditions.

I spent roughly 80 times more on one coding task using GPT-5.6 Sol than I did using Grok 4.5 in Cursor, while the difference in the final result was negligible. This was one real-world task—not a universal benchmark. Cursor pricing, token usage, reasoning effort, caching, and model behavior can all affect the final cost.

Per-token pricing alone does not determine the economics. A model that reasons longer, produces more tokens, or invokes more agents can become substantially more expensive before the user sees a meaningfully better result.

A good harness can mitigate many remaining model differences through better context and task decomposition, planning and validation loops, automated tests and evaluations, model routing, and escalation to expensive models only when needed.

The winning architecture probably will not use the best model for every task. It will use the cheapest model that reliably clears the quality bar and selectively escalate when the expected improvement justifies the cost.

Autonomy should be treated as a measured privilege, not a default setting. In regulated environments, the agent's technical capability is only one part of the decision. The system also needs a clear view of task risk, reversibility, confidence, cost, and the blast radius of a bad action.

That is the idea behind Agent Autonomy Score: make supervision a first-class control. Low-risk, reversible work can move quickly. High-risk work should slow down, ask for review, or provide a stronger audit trail before it touches production systems or client-facing workflows.

The teams that win with agentic AI will not be the ones that give every model unlimited agency. They will be the ones that can explain why an agent was allowed to act, when it was stopped, and what evidence the system used to make that call.

Most early multi-agent prototypes wire agents together with direct calls: planner calls researcher, researcher calls analyst, analyst calls writer. That works for demos, but it creates brittle dependency chains as soon as the system needs reliability, observability, or live upgrades.

An event-driven model is a better fit for production. Agents subscribe to the work they understand and emit structured events when they complete, fail, escalate, or need more context. That makes it possible to add a new specialist agent, replace an expensive model, or replay a workflow without redeploying the entire system.

For enterprise AI, the architecture around the model matters as much as the model itself. Service buses, durable queues, event envelopes, registries, and cost telemetry are what turn a clever agent chain into software that can survive real usage.

The best AI-assisted development work is not about asking a model for code and hoping the patch is good. It is about designing the workflow around the model: what context it receives, what tools it can call, what checks run automatically, and where humans review the result.

Inside large organizations, that workflow has to account for governance, cost, security, and team adoption. The point is not to replace engineering judgment. The point is to compress the boring parts of implementation while making the review surface clearer and more measurable.

The practical metric is whether the system helps teams ship reliable software faster. That means tracking more than token spend or lines of code. It means connecting agentic compute to outcomes: cycle time, review burden, defect rate, and how often the automation makes a human decision easier.