Portfolio · 2026

Andrew Gordieiev

AI Solutions Architect. I build production-grade agentic systems and the engineering practices that make them sustainable — bridging hands-on multi-agent architecture with organization-wide AI capability rollout. 20+ years in software, 8+ in architecture leadership.

View work Get in touch CV (PDF)

Multi-agent architectureProduction AI deliveryAI practice rolloutEnterprise guardrails

About

Three lines, no marketing

I'm a software architect who spent the last few years moving from classical distributed systems into agentic AI — design, implementation, and rollout of multi-agent platforms inside teams that ship to real users.

Right now I build a 50-agent SDLC platform that takes a feature spec and walks it through architecture, design, code, review, QA, and deploy with explicit human-in-the-loop gates — and I run the same playbook to roll AI capabilities across engineering organizations.

What I optimize for is durability of the resulting system: tests, observability, governance, and the team practices that survive the architect leaving the room.

Selected Work

Three production-grade engagements

A flagship multi-agent platform, an organization-wide AI practice rollout, and an enterprise guardrails framework. Each addresses a different binding constraint: technology, organization, governance.

Case 01

Flagship · Multi-agent platform

Agentic SDLC Platform — 50 agents, spec-to-prod in 1–2 days

xteam is an agentic SDLC platform — 50 specialized agents organized into 11 functional groups, paired author + auditor for nearly every artifact, and a single cross-cutting Navigator that tells the operator what phase the project is in and which agent should run next. The platform turns a feature spec into a deployed increment in 1–2 days while preserving the engineering practices a senior architect would demand: typed contracts, scored audits, anti-mock test guards, canary + synthetic + rollback + kill-switch on the deploy side, and an explicit Ship-to-Prod 19-position gate that blocks releases until every layer is verified on HEAD. The system has processed roughly 500 features across three domains — fintech SaaS, multi-modal comic production, and developer tooling — without losing the human-in-the-loop discipline. Every irreversible operation routes through an approval gate; every audit produces a numerical score and a list of binary gaps; every gap has a named owner and a re-evaluation trigger.

Interactive · 1 of 3

Agent topology

Hover or click any node to inspect role, paired auditor, and an example of work. Author/auditor pairs are highlighted by a dashed link when an agent is selected.

Interactive · 2 of 3

Workflow walkthrough

Step through the SDLC pipeline from spec to deploy. Each stage shows its agents, input, output, and the binary approval gate that must score ≥ 99/100 before the artifact moves on.

SDLC Walkthrough

Spec → Production, with explicit gates

Stage 1 of 8

Specify

An idea hits the system as plain prose. xSpecifier converts it to structured user stories, functional requirements, and binary acceptance criteria. xSpecAuditor scores the spec and bounces it back if traceability is broken.

xSpecifierxSpecAuditor

Input

Raw idea / user story

Output

spec.md with FRs, ACs, success criteria

Approval gate

Spec must score ≥ 99/100 on auditor rubric.

Interactive · 3 of 3

Navigator simulator

The Navigator is the cross-cutting agent that reads explicit signals about a project (not heuristics) and proposes the next action plus the agent best placed to take it. Pick a scenario.

Navigator

Project state → suggested next step

Pick a project state. The Navigator reads explicit signals (not heuristics) and recommends the next action and the agent best suited to take it.

Signals

No .specify/ directory
No spec.md, no architecture.md
Idea: 'a tool to help recruiters screen LLM portfolios'

Phase

DISCOVERY

Next action

Convert the idea into a problem statement, ICP, and JTBD before any architecture decisions.

Suggested agent

xAnalyst

Architecture without a problem statement produces over-engineered systems for the wrong user. Discovery-first prevents premature commitment to a stack.

Agents: 50 across 11 groups
Spec → deployed: 1–2 days
Features processed: ~500
Domains: Fintech SaaS · Comic studio · Dev tooling
Author/auditor pairs: 12 explicit symmetries
Production gate: Ship-to-Prod 19-position binary

Case 02

Process · AI practice rollout

AI Practice Rollout — foundation-first across 300+ engineers

Foundation-first AI practice rollout inside a 300+ engineer IT services firm. A small core architecture team (5 architects) carried a single thesis: the binding constraint on AI adoption is organizational, not technical. We built a foundation layer — AI policy, reference architectures, eval frameworks, prompt and agent libraries — and ran it through four pilot engagements (TMS rebuild, fintech ledger, internal dev tooling, mobility B2B). Each pilot produced a characteristic velocity signature: a 2–3 week dip while engineers learned the flow, then a sustained uplift to ~2–2.5× pre-adoption throughput. Foundation patterns that generalized fed back into the layer; patterns that didn't stayed scoped to their pilot. By the end of the engagement, AI capabilities had landed across 20+ projects with measurable tier-up rates among the broader engineering population. The deliverable was not a tool — it was a way of running pilots that survives the architects leaving the room.

Diagram · 1 of 2

Adoption curve — dip, then uplift

Three pilots, each running 12 weeks. Velocity dips for ~3 weeks as engineers learn the new flow, then crosses the baseline and stabilises at roughly 2–2.5× of pre-adoption throughput. The foundation layer (policies, refs, eval frameworks) shortens the dip for every subsequent pilot.

Pilot A · TMS rebuild
Pilot B · Fintech ledger
Pilot C · Internal dev tooling

Diagram · 2 of 2

Foundation-first practice architecture

Pilots feed the foundation layer; the foundation layer shortens the next pilot. Adoption metrics close the loop and decide whether the foundation pattern generalizes or stays pilot-specific.

Org size: 300+ engineers
Core team: 5 architects
Client pilots: 4 engagements
Project coverage: 20+ projects
Sustained uplift: ~2–2.5× baseline
Tier-up: ~50% of engineers (directional)

Case 03

Governance · Enterprise AI guardrails

Enterprise AI Guardrails — propose, never apply

Two-phase engagement inside a European mobility enterprise (5,000+ employees). Phase 1 was a Transportation Management System delivered from scratch on Java/Spring/Azure with a 30–40 person team — a multi-year program of typed APIs, event-driven domain modules, and CI/CD against a regulated production environment. Phase 2 was an AI guardrails framework for a broader subsystem (150–200 dev/test engineers) where the binding constraint was governance: any AI-driven change had to remain inside the internal perimeter, must never exfiltrate data, and must pass multi-criteria automated review plus a human approval gate before being applied. The framework runs a Python orchestrator that dispatches builder and validator agents in parallel; only patches that pass both an automated multi-criteria score and a human reviewer reach the Java ecosystem fix agents. The pattern is "propose, never apply" — agents produce diffs and rationales, humans accept the change. Coverage augmentation is automated against the same gate. The framework now operates as the standing AI integration pattern for the subsystem.

Diagram · 1 of 1

Approval-gated agentic workflow

Builder and validator agents run in parallel against the same spec. Both outputs converge on a human approval gate. Only approved patches reach the Java fix agents — the system proposes, never applies.

Enterprise scale: 5,000+ employees
Phase 1 team: 30–40 engineers
Phase 2 reach: 150–200 dev / test
Stack: Java · Spring · Azure · Python orchestrator
Pattern: Propose-only · human approval gate
Perimeter: Internal only · no exfiltration

Approach

Four principles I keep returning to

Build for production, not demos.

A demo is a shape; production is a contract. Most agent failures aren't model failures — they're the missing tests, the unhandled failure modes, the absent rollback paths, the silent skips. I treat agentic systems the way I treat any other distributed system: typed contracts, schema-validated boundaries, explicit error taxonomy, observability at every step. The interesting question isn't whether the LLM produced something plausible — it's whether the system stays correct when the LLM doesn't.

Organizational change is the binding constraint, not technology.

Bringing AI into an engineering org of 300+ people, the bottleneck is rarely the model or the tooling — it's adoption mechanics. Engineers need a runway short enough to feel velocity uplift before they abandon the new flow. Managers need measurements that cut through hype. I plan rollouts as a sequence of low-risk pilots feeding back into a foundation layer (policies, refs, eval frameworks) so every subsequent project lands faster than the previous one.

Human-in-the-loop as architectural principle.

The agents that work in production are the ones that propose and never apply. Approval gates aren't a UX afterthought — they're a structural feature: every irreversible operation routes through a human review step with a diff, a justification, and a rollback path. This is non-negotiable for code, for infrastructure, for any system that touches customer data.

Fundamentals-first over license-first.

Picking the latest framework before the team understands the underlying patterns produces fragile systems. I push teams to learn the primitives — message protocols, tool-use semantics, eval design, prompt-engineering as a discipline — before locking into a vendor stack. Vendors change. Patterns persist.

Background

Twenty years, three arcs

2024 — present
AI Solutions Architect
Multi-agent SDLC platform (xteam, 50 agents, 11 functional groups). AI practice rollout across an IT services organization (300+ engineers, 4 client pilots). Enterprise guardrails framework for a European mobility company.
2017 — 2024
Software Architecture Lead
Architecture leadership across distributed systems, SaaS platforms, and large enterprise programs (TMS, fintech, mobility). Led delivery teams of 30–40 engineers; shipped production systems on Java/Spring/Azure and Node/TypeScript stacks.
2005 — 2017
Senior Backend Engineer → Tech Lead
Java backend specialist. Domain work in fintech, telecom, e-commerce. Moved from individual contributor through tech lead into architecture as systems and teams grew.

Selected affiliations

Oxagile · European mobility enterprise (Phase 1 & 2) · Multiple fintech and SaaS clients

Full CV (PDF)