Most technology consulting firms talk about AI as something they’ve added. CapNexus was built around it.
The company launched in March 2026 through the combination of three firms: Capstone Integrated Solutions, which brought cloud engineering, AWS architecture, and large-scale system modernization; RPE Solutions, founded in 1999, which brought more than 25 years of enterprise consulting, Blue Yonder implementations, and IBM Power Systems expertise including a SOC 1 and SOC 2 Type 2 compliant data center; and Makira, a retail implementation firm with deep roots in the Aptos ecosystem. Together, they serve enterprise and retail organizations across cloud adoption, AI, supply chain operations, legacy modernization, and managed services as an AWS Advanced Tier Services Partner.
The interesting part isn’t the combination itself. It’s what CapNexus decided to do with AI. Most firms build an AI team and route work to it. CapNexus put AI into each of its practices instead, changing what those practices recommend to customers and how their offerings work. The supply chain team is rethinking demand planning with AI at the center rather than adding AI to it. The legacy modernization team is redesigning the modernization path so that AI is part of the destination.
“We didn’t merge three companies to build a generalist firm,” CEO Marty Hendrickson says. “We merged them because each one had gone deep in a space that matters. The job now is to keep that depth, connect it, and make sure AI runs through all of it rather than sitting off to the side.”
Hendrickson built his leadership team around that idea: four practice leaders who are practitioners first, one sales organization selling across all of them, and one person responsible for keeping AI and delivery standards consistent firm-wide. That last job went to Tony Santiago, who wasn’t hired to do it.
From AI Practice to Delivery Organization
Santiago came to CapNexus to lead the AI practice. He spent the six years before that at AWS as a Worldwide Partner Solution Architect, helping global systems integrators build their Generative AI and Agentic AI practices. He worked alongside their leadership teams to shape how they’d serve joint customers, and sometimes got pulled into strategic deals where he worked directly with the partner to win. But most of his time was spent helping these firms stand up the methodologies and teams they needed to deliver AI at scale.
During that time, he led the Platform Perspective of the AWS Cloud Adoption Framework, the prescriptive guidance AWS publishes to help enterprises structure their cloud adoption. He also contributed to the AWS Cloud Adoption Framework for AI, ML, and Generative AI, where he’s listed as CAF Platform Perspective Lead. Those frameworks exist because AWS recognized that cloud and AI adoption aren’t purely technical problems. They’re organizational ones.
“The pattern I watched repeat at AWS was the same across every partner and every customer,” Santiago says. “A team would build a proof of concept. The demo would land. Leadership would get excited. And then somewhere between successful pilot and the business runs on this, everything stalled. Not because of the models. Because the operational questions hadn’t been answered.”
MIT’s Project NANDA measured that gap in 2025. Of the organizations evaluating generative AI tools, 60% ran an evaluation, 20% reached a pilot, and 5% reached production. The technology works. What’s missing is the operational layer underneath it.
So the AI practice he built at CapNexus starts engagements with questions that have nothing to do with models. Who owns this once it’s live? How does drift get monitored? What happens when the underlying data changes? Who retrains, and on what schedule? As the practice matured, a related set of questions kept surfacing in engagements that had nothing to do with AI. How does work get scoped? Who signs off on quality? What happens when a solution moves from the team that built it to the team that runs it?
Hendrickson’s answer was to widen the job. Rather than keep AI as its own practice with its own delivery team, he brought all of the firm’s delivery people into one organization and put Santiago in charge of it, along with the AI work and the quality standards that apply across every practice. Santiago is now Managing Director of Firm Architecture and Delivery.
CapNexus doesn’t start with the technology. It starts with whether the organization is ready to run what gets built.
Four Practices, One Delivery Team
Each of the four practices is led by someone who has built their career inside the discipline they now lead.
1. Agentic and Digital
covers cloud and application modernization with AI-native delivery. This practice handles work at the intersection of cloud engineering and AI, from Amazon Bedrock deployments to agentic systems built on Amazon Bedrock AgentCore.
2. Supply Chain and Demand Optimization
is led by Mark Stanford, who has spent more than 20 years in merchandise management, planning, allocation, and replenishment. Stanford’s team works inside the operational realities of how retailers and CPG companies actually forecast and plan demand. The firm’s work with Amazon Connect Decisions sits here, combining that planning expertise with the AI architecture to make demand planning faster and more connected.
“The planning teams I’ve worked with for years, they don’t need another dashboard,” Stanford says. “They need the three forecasts they’re already running to talk to each other. That’s a domain problem first and a technology problem second.”
3. Core Systems and Modernization
focuses on IBM i, AS/400, RPG, and COBOL environments, the systems of record that many large organizations still depend on for order processing, inventory, financials, and compliance reporting. CapNexus inherited RPE Solutions’ data center and IBM Power Systems expertise, and built a three-stage modernization framework around it: Move (managed infrastructure), Mesh (integration and connectivity with cloud-native services), and Modernize (full application transformation). For many of these organizations, unlocking the data trapped inside decades-old systems becomes the first real step toward AI and advanced analytics.
4. Retail Integrations and POS,
led by Andrew Miller and Rick Boretsky, covers the Aptos ecosystem, JumpMind, omnichannel commerce, and retail system integration. This team came through the Makira acquisition and carries the implementation expertise that retailers depend on for their customer-facing technology.
The practice leaders set direction for their disciplines. The people who build and run the work all sit together in one organization, which means an engagement that needs supply chain expertise and cloud engineering gets both, staffed from the same team.
It also means the people who design a solution are the ones who run it afterward. That matters most on complex engagements where legacy systems, cloud infrastructure, and AI all have to work together, and where a handoff would create exactly the kind of gap that stalls projects.
Internally the firm describes the arc as Plan, Deliver, Run. Plan covers strategy, assessment, and prototyping, where CapNexus figures out whether an idea is viable and what it would actually take. Deliver is the engineering. Run is managed services, keeping the solution working and feeding what they learn back into the next round of improvements. Enterprise projects often split those three stages across different firms, and that’s usually where accountability disappears.
AI in Every Engagement
Ask which CapNexus practice handles AI and the answer is all four. A retailer integrating a new point-of-sale system and a manufacturer modernizing an AS/400 both end up working with AI-native capabilities, because each practice has been rebuilt to work that way.
Part of that is shared plumbing. Every engagement draws on the same AI architecture, tooling standards, and governance frameworks no matter which practice brought the customer in. Agents built by any of the four practices run on Amazon Bedrock AgentCore, which handles runtime, gateway, memory, identity, observability, and policy enforcement, so an agent operates inside defined boundaries from the start rather than having controls retrofitted after something goes wrong.
The harder part is that each practice is rethinking its own offerings around what AI now makes possible, which changes what its people recommend when they sit down with a customer.
Doing that consistently across four disciplines takes a shared way of talking about capability, and the framework CapNexus built for it started with a complaint. Companies kept asking for AI maturity assessments and getting back a single score that told them nothing about what to do on Monday.
The firm’s answer is a model it calls the Capability Flywheel, which breaks any capability into four stages. Govern is who can change something, at what risk, with what audit trail. Structure is the systems and data the capability runs on, and whether any of it is fit for purpose. Build is the production estate that turns that material into outcomes. Enforce is how the thing stays running, gets costed, resists drift, and improves. That Govern comes first and Build comes third is deliberate, and it’s the order most organizations reverse.
Each stage carries its own maturity, which is the part that changes the conversation. A company isn’t mature at AI or immature at it. It might have solid data foundations and no governance, or good controls over a production estate nobody can monitor. Naming maturity stage by stage exposes which one is actually holding the others back.
That weakest stage is the constraint, and directing investment there is what makes the capability compound rather than just improve. Better monitoring in Enforce feeds back into what Govern permits and what Structure needs to fix. Cleaner data makes everything built on top of it work better. Every pass through the loop makes the next one turn faster, which is why the model is called a flywheel and not a checklist. Put money into a stage that isn’t the constraint and the wheel just sits there. It’s Theory of Constraints pointed at capability building rather than manufacturing throughput.
That design is also why the model outgrew its origins. It started inside the AI practice with AI-specific measures like RAG maturity and model serving, but the stages and the constraint logic were never about AI. The supply chain team now writes its own measures against the same four stages, and so does the team working on IBM i, which means a customer with problems in both places gets one coherent read rather than two unrelated assessments.
CapNexus runs the assessment on itself, practice by practice. Santiago’s position is that a firm that can’t pass its own diagnostic has no business selling it.
Rebuilding Demand Planning
The clearest example of that is in supply chain. CapNexus has been working with AWS as an early partner for Amazon Connect Decisions, AWS’s agentic supply chain planning and intelligence solution. The product combines 30 years of Amazon operational science with AI teammates that work alongside planning teams to harmonize demand signals into consensus forecasts, generate constraint-aware supply plans, and monitor operations across the supply chain.
The engagement needs two kinds of knowledge that rarely sit in the same firm. Stanford’s team knows how retailers and CPG companies actually run demand planning, what the Monday morning planning meeting looks like, and why reconciling buying, planning, and supply chain forecasts takes weeks instead of hours. The AI architecture underneath it is the same one every practice draws from, and it’s what makes the technology hold up in production rather than in a demo. Neither piece gets there alone.
Parts of the platform, including supply planning, are still in preview, which is the stage at which a delivery partner’s judgment matters most. The questions coming from planning teams at this point are about workflow and trust rather than features.
Born from Application Development
CapNexus is a development shop before it’s anything else, and that shapes what it does with a legacy system. Engineers who spent their careers writing applications tend to ask what an application should become, not just where it should run. Much of the AWS partner field grew out of infrastructure, where the natural question is where the workload lands.
The range of that development bench is unusual. There are RPG developers who can read a twenty-year-old order processing system and explain what the business logic actually does, which is rarer every year as that generation retires. There are cloud-native engineers building serverless and containerized applications on AWS. There are data engineers, platform engineers, and AI engineers. Most firms have one end of that spectrum or the other. Having both is what makes it possible to modernize a system rather than replace it and hope.
The difference shows up in outcomes. An application lifted onto new infrastructure without changing how it’s built is the same monolith on a more expensive platform, which is why the Move, Mesh, Modernize path described earlier lets a company stop where the business case runs out rather than committing to a multi-year overhaul.
Modernization is also what makes AI possible. Companies that have reworked their data architecture and connected their legacy systems to cloud-native services can put AI to work on data that used to be unreachable. Companies that haven’t are building AI on top of information they can’t get to.
Agentic Engineering at Delivery Scale
The development bench is where CapNexus has done its most specific work, and the starting point is that most AI coding rollouts produce no measurable gain.
The data on this is unflattering. Faros AI analyzed telemetry from 10,000 developers across 1,255 enterprise teams in 2025 and found that teams with heavy AI adoption merged 98% more pull requests, but review time rose 91% and there was no correlation between AI adoption and better outcomes at the company level. GitClear, working from hundreds of millions of code changes, found refactoring down roughly 70% since 2022 while duplicated code climbed sharply. Developers are now several times more likely to copy and paste than to restructure what already exists.
Santiago’s read is that the tools work fine and the failure is structural. Asking a model for the next function is a different activity from engineering the system that produces the code, and only one of them moves a delivery organization’s numbers. The first is what most teams are doing. CapNexus calls the second agentic engineering, and treats it as a discipline its engineers are trained in rather than a tool they’re issued.
Around that sits a methodology the firm calls AIDLC, the AI Development Lifecycle. Its premise is narrower than most AI-and-coding pitches: AIDLC governs how custom software gets produced when AI is the primary means of production. Not AI features in the shipped product. AI as the means by which engineers build it. That holds whether what ships is a machine learning workload or ordinary application logic. The two layers do different jobs, with AIDLC defining how an engagement is delivered, gated, and evidenced, and agentic engineering defining how an individual engineer works inside it.
AIDLC runs in three phases CapNexus named itself: Frame, Loop, and Ship. Frame is problem definition, architecture, and grounding the work in the customer’s actual context. Loop is the iterative generate-and-validate cycle. Ship lands the artifact and hands off ongoing operation. Underneath the vocabulary sits something more consequential, which is that AIDLC is anchored on ISO/IEC 5338 and NIST SP 800-218A, the international standards for AI lifecycle management and secure software development. For a customer in financial services or healthcare, that anchoring is what makes an AI-built system defensible to an auditor.
The iteration cadence changes too. Two-week sprints assume humans are the constraint on how fast code gets written. When agents are generating and testing, the unit of work compresses to hours or days, and CapNexus runs what it calls Bolts instead. Given the research above, that compression is also exactly where discipline matters most, which is why the firm declines to make the 10x productivity claims common elsewhere in the market and commits instead to publishing its own outcomes.
Increasingly the work isn’t just building software for a customer. It’s making the customer’s own team faster. CapNexus embeds engineers directly into client teams under a model borrowed from Palantir’s forward deployed engineering practice: an engineer works alongside the client’s developers, ships production code rather than recommendations, and leaves behind templates and patterns the client’s own people can extend. The measure of success is when the client’s developers are building their own accelerators without help. That’s a different sale than a staffed project, and it only works with a library of reusable assets underneath it, which is the part the firm has spent the past year building.
What Comes Next ?
CapNexus is betting that the consulting firms that matter in the next decade will be the ones that treat AI as infrastructure rather than as a service line. The technology is ready. The platforms are catching up, with Amazon Connect Decisions and Amazon Bedrock AgentCore both built for production rather than demos. What’s still missing at most companies is the operating model to run any of it at scale.
That’s the gap the firm organized itself around. Four practices with real depth, each rebuilding its offerings around AI. One team that builds and runs the work. And a set of standards that keeps the AI consistent whether the engagement started in supply chain or on an AS/400.
“None of this works as one person’s idea,” Hendrickson says. “It works because the practice leaders and the delivery team agreed on how to work together.”
For more information about CapNexus and our AWS cloud services and solutions visit: https://capnexus.io/cloud-migration-and-modernization-on-aws
Also Read :- CIO Times Magazine for More Information
