Selected work

Validation-first: a multi-site Hyper-V & SCVMM residency

For a global IT services firm's state-government end client · delivered under a Dell residency contract

The client's engineers had already done the heavy lifting: hosts deployed, failover clusters formed, the network fabric built across two sites. What they asked for was not a rebuild — it was certainty. Had it been built right? Would it hold in operation? And what should the management layer look like?

We structured the residency around that question. The first three weeks were pure validation: host configuration, cluster behavior, storage and network paths — tested methodically, with findings documented as we went. No inherited assumptions, no credit given for "should be fine."

On that validated foundation, we designed the SCVMM target state and built it out across both sites, followed by enablement sessions so the client's team could run what they now owned.

The moment we tell this story for came midway through: the customer's engineering team reviewed our target-state design and challenged one of its core decisions — where the ownership boundary between Network ATC and SCVMM should sit for network configuration. They were right to push. We revised the design, and version 1.1 carries their review: a cleaner split of who manages what, agreed line by line with the people who operate the platform.

Some consultancies would call that scope friction. We call it the engagement working as designed — we engineer with the customer, not at them. A design that survives the customer's own engineers is worth more than one that was never challenged.

What remained when we left: validation reports, the revised target-state design, build documentation, and a team enabled to operate the platform. Every hour of the residency left an artifact behind.

An application-migration methodology, industrialized

Active application-migration engagement with Dell · B2B2B delivery

Application migrations rarely fail in the tooling. They fail in the gaps — between discovery and planning, between the runbook in someone's head and the one executed at 2 a.m., between "we can roll back" and an actual, tested rollback plan.

In our engagement with Dell, we took Dell's three-phase migration methodology and industrialized it: not a slide framework, but a governed migration factory.

How the factory works:

• Phase gates. Each phase ends in a gate with defined entry and exit criteria. Nothing moves forward on momentum.
• Generated runbooks — and generated rollback plans. For every move group, the factory produces the forward path and the way back, in consistent, reviewable form. The rollback plan is not an afterthought; it is generated alongside the runbook, every time.
• Human go/no-go. AI agents prepare the evidence — discovery synthesis, dependency mapping, validation checks, documentation. A human makes every gate decision. No migration step executes on an agent's say-so.
• Full traceability. Every decision and action is logged and attributable: what was done, when, by whom, on whose approval.

We are deliberate about what this page claims. This is a methodology and capability story: the factory is productized inside an active Dell engagement, delivered B2B2B to Dell's customers. We will publish outcomes when customer migrations complete — not before.

If your migration backlog looks like a long row of heroic one-off projects, the factory model is the alternative: industrial consistency in the artifacts, human judgment at every gate.

Agentic delivery, engineer-supervised

Our delivery model · how every Gus IT engagement runs

The first question a serious buyer asks about AI-driven delivery is the right one: is it safe to let AI agents near production infrastructure?

Our answer is a strict division of labor, applied on every engagement.

What our AI agents do: the repetitive engineering that consumes senior time and invites human error. They run discovery across estates, synthesize configurations into documentation, generate runbooks and rollback plans, execute validation checks, and keep the paper trail current — consistently, at any hour, without fatigue.

What they never do: approve a design. Touch a production system unsupervised. Make a go/no-go call.

Every engagement has a named senior engineer who owns design approval and every state-changing action. Our automation is built dry-run-safe: it can be rehearsed without touching live systems, and every phase carries a rollback plan before it carries a change. Every action — human or agent — is logged and attributable, so you always know who decided and who acted.

Why this matters to you: you get the consistency of a factory in the artifacts — documentation that is actually complete, runbooks that are actually current — without surrendering judgment to a machine. The engineer is not reviewing the AI's homework after the fact; the engineer is the gate the work passes through.

This is not a lab concept. It is how we deliver our contracted work today, including engagements under partner and channel contracts.

If you are weighing whether AI belongs in your delivery chain — or how to govern it once it's there — bring your hardest questions to the assessment call. This model is built to be interrogated.