The biggest barrier to AI adoption isn’t awareness. It’s the gap between talking about AI and building with it.
Professionals whose primary role isn’t writing code, but whose daily work increasingly depends on AI solutions, don’t need engineering backgrounds to start building AI capability. They need the right tools, structured support, and permission to fail. Here’s how we proved it, and how you can replicate it.
The problem organizations are ignoring
Your teams are already in AI conversations, whether they’re fielding questions from customers, evaluating vendor solutions, or identifying automation opportunities in their day-to-day responsibilities. Given the pace at which agentic AI tools have become generally available, most of them have never built anything with the tools they’re discussing.
These teams, regardless of whether they sit in sales, operations, finance, or product, have watched the demos and completed the certifications. But when someone asks, “how does this actually work?”, they don’t have the answer that comes from having built with it themselves.
The cost is real: slower adoption, delayed productivity gains, missed opportunities to identify use cases, and a growing disconnect between what your teams know about and what they can implement.
We asked business professionals, people who work with AI tools daily but aren’t writing production code, what held them back with AI adoption. The answer wasn’t “I don’t want to learn.” 90 percent wanted hands-on experience building AI agents. They were missing the connective tissue and scaffolding to build safely. The following chart illustrates the most common barriers business teams face when attempting to build with AI.
Figure 1: Top barriers business teams cite to building with AI
At a high level, they could talk about Amazon Bedrock and Amazon Bedrock AgentCore, a platform to build, connect, and optimize agents at scale with any framework or model (80 percent had explored it). But fewer than 1 in 5 had touched Strands Agents SDK or built with AWS Lambda agents. They were opting out of hackathons and build events because they didn’t believe their technical knowledge was strong enough to compete alongside engineers.
To solve for this, we designed a six-week structured program that pairs business professionals with mentors and production-grade tools to build working AI prototypes that can scale beyond the program. The goal: close the gap between conceptual knowledge and hands-on capability.
What one team built: The proof in six weeks
Four customer-facing professionals who had never worked together participated in our program. None had engineering backgrounds. Six weeks later, they presented their prototype, WealthWise, a multi-agent AI financial advisory tool, that won first place.
What they built:
- Five specialized AI agents delivering intelligent financial advisory: portfolio analysis, risk assessment, financial planning, market insights, and personalized investment recommendations.
- Dual-server architecture (
Node.js+ Python Flask) with Amazon Nova models.* - Strands Agents SDK for multi-agent orchestration and conversation memory.
- Four Amazon DynamoDB tables for real-time data persistence.
- Live market data integration for context-aware financial recommendations.
- Sub-5-second response times for complex financial reasoning.
The system features coordinated decision-making: Each agent independently decides which tools to invoke and chains multiple tools together, performing multi-step reasoning across portfolio data, market databases, and financial planning models.
They attributed their success to five principles they established on day one:
- Learning over winning – Choosing challenging approaches over safe shortcuts freed them to experiment without fear.
- Regular cadences – Daily standups prevented isolation and caught issues early.
- Start with a Minimum Viable Product (MVP), then refine – Working end-to-end flow by Day 2, then iterate.
- Engage in office hours – Actively seeking mentorship when stuck.
- Have fun – Psychological safety before technical output.
Participants reflected on how the hands-on format accelerated their learning:
“The hackathon’s timing was perfect, and the hands-on format proved invaluable for AgentCore enablement – accelerating what could have been a lengthy learning curve.”
“Great teambuilding and AI learning project! I taught myself a lot and have additional empathy for customers who are new to AI solutions.”
* Amazon Nova models are available on Amazon Bedrock in select AWS Regions. For the latest availability, see the AWS Regional Services page.
The playbook: How we designed the program
The following sections break down the program structure, each phase, and the design decisions that made it work.
Program structure
The program runs over six weeks, with participants dedicating approximately four hours per week. We structured it this way deliberately: based on our program data, participants who completed a phased program retained three times more practical skills than those in intensive two-day formats. Professionals who don’t write code for their primary jobs need iteration cycles: time to struggle with unfamiliar concepts, recover, and build again before confidence becomes durable.
Phase 0: Recruitment and program setup
We recruited participants through manager nomination, Slack, and email campaigns, targeting professionals who work with AI solutions daily but don’t build them: account managers, solutions consultants, operations analysts, program managers, and similar roles. Management buy-in came first. We briefed team leaders on the time commitment (four hours per week for six weeks) and framed it as an investment in fluency and conversation quality, not a distraction from their day-to-day delivery.
The program was orchestrated by four core team members plus mentors who ran it alongside their day jobs. That’s a key replicability point: this doesn’t require a dedicated program team, but it does require at least one person with enough organizational trust to protect participants’ time.
Phase 1: Team formation and kickoff
What participants do: Form teams of 3–4 with intentionally mixed experience levels. Teams define a problem statement tied to a real scenario they’ve encountered in their role.
What this produces: A scoped project concept that can be demoed and team accountability structure.
Why this matters before moving on: Without a concrete problem to solve, enablement sessions become abstract. Teams who define their target use case first absorb technical content with purpose.
Phase 2: Enablement
What participants do: Attend live training sessions on agentic AI concepts and AWS tools. These are not lectures. Participants work inside the actual tools they will use in the build phase, completing structured exercises that mirror their project work.
What this produces: Baseline technical fluency and a working local environment.
Why this matters before moving on: Teams who skip straight to building hit a wall at environment setup and foundational concepts. This phase avoids the most common drop-off point.
Phase 3: Ideation, building and development
What participants do: Design and iterate on working prototypes over multiple weeks. Each team is paired with a technically proficient mentor who provides a safety net, unblocking infrastructure issues and suggesting architectural patterns without doing the work for them.
What this produces: A functional prototype that could be demoed to a stakeholder or customer.
Why this matters before moving on: The extended timeline allows 2–3 iteration cycles. Teams who built a prototype in week 3 had time to continuously apply new learning, tear it down, and rebuild better in week 5. That iteration is where the real learning happens.
Phase 4: Judging and demos
What participants do: Deliver live demonstrations evaluated across five categories: Business Impact, Technical Excellence, Reusability and Scalability, Innovation, and Presentation Quality.
What this produces: Peer-validated proof of capability and a library of reusable prototypes.
Why this matters: The demo format mirrors what participants will do in real conversations with customers, leadership, and cross-functional partners. Judging criteria reinforce that working isn’t enough. It has to be impactful, scalable, and clearly communicated.
Critical design decisions
Tool selection is the most important decision for builders who aren’t engineers. The wrong tools create friction that halts momentum. The right ones abstract infrastructure and meet people at their current level of expertise. We chose:
- Kiro Integrated Development Environment (IDE) for natural-language development: describe what you want, and it scaffolds the architecture.
- Amazon Bedrock for API-accessible foundation models available in that Region: no machine learning (ML) expertise required to get a working response from a model.
- Strands Agents SDK for composable agent patterns: agents compose like building blocks.
- AWS Model Context Protocol (MCP) servers and AWS Lambda agents to push teams toward deployable, production-grade architectures, not only local notebooks.
The core principle never changed: build something real that you could demo on short notice.
Managing day-job disruption
We deliberately capped weekly commitment at four hours and gave participants flexibility on when those hours happened. The most common feedback was that participants applied what they were learning directly to their work within the first two weeks, making the time investment feel additive rather than competing.
The results
The following chart compares participant self-assessments before and after the program across eight key metrics, including AI competency, tool adoption, and readiness to apply learnings with customers.
Figure 2: Participant self-assessments before and after the program
Going in, participants cited “lack of real-world examples” as their top barrier to building with AI. Coming out, 23 percentage points (pp) more participants rated themselves confident in applying AI to practical use cases than expected to be at the start. Participants left the program with a working prototype, a code repository, and a reference architecture they could demo to stakeholders immediately.
What they built and are bringing to customers:
- Multi-agent care coordination for healthcare independent software vendors (ISVs).
- Content moderation and triaging systems.
- Fraud identification and prevention.
- Customer churn prediction and prevention.
- Multi-agent orchestration for autonomous decision-making.
- Kiro + Amazon Bedrock AgentCore demos for customer workshops.
The impact: From observers to builders
When our participants gained hands-on access to AI tooling, they moved from discussing possibilities to building working prototypes. The numbers tell the story:
- Self-rated ‘Strong or Expert’ understanding of agentic AI: increased from 27 percent to 82 percent (+55 pp).
- Feeling ‘Well or Extremely prepared’ to identify AI opportunities: increased from 41 percent to 85 percent (+44 pp).
- Participants with only theoretical or limited experience: decreased from 34 percent to 0 percent (removed).
Here’s what investing in this unlocks:
For your teams: They stop being AI observers and become AI builders. They know what’s feasible, what’s expensive, and what’s a weekend build from direct experimentation. In our cohort, 52 percent identified specific customers who could benefit from what they built during the program, and 87 percent expected to apply their learnings with customers within 30 days. The program over-delivered on practical use cases because it required them to create the examples themselves.
For your engineering orgs: When business counterparts can prototype and articulate architecture tradeoffs, engineering teams spend less time translating requirements and more time building. Technical builders get clearer intake, fewer misaligned requests, and partners who can pressure-test feasibility before a single sprint is committed. Consider: 82 percent of participants left with a strong understanding of agentic AI architecture. Tool fluency surged across the stack: Strands Agents SDK went from 20 percent to 80 percent adoption (+60 pp) and AgentCore from 39 percent to 85 percent, raising the bar on engineering judgment.
For your customers: They get partners who’ve navigated the same architectural tradeoffs they’re facing by having direct, hands-on experience. Conversations move from “let me get back to you” to live walkthroughs. Before the program, 44 percent of participants cited uncertainty about architecture patterns as a barrier. After the program, 90 percent felt well prepared or better to identify AI opportunities in real customer conversations.
For your organization: You get a replicable model that compounds. Our pilot’s expansion from one team to regional and now global deployment demonstrates the pattern: hands-on fluency scales itself. The program achieved a 100 percent recommendation rate, with 95 percent of participants saying the program met or exceeded expectations.
Seven lessons for replicating this at your organization
These seven lessons capture what made the program work and what to replicate in your own organization.
1. Tool selection changes everything
Low-code, agentic experiences remove the “I’m not technical enough” barrier. This is a program design decision, not a procurement afterthought. If your tools require Python fluency, you’ve lost half the room before week one.
2. Structure beats intensity
A phased program (6 weeks) with clear milestones outperforms a two-day sprint for non-technical audiences. Expect the first week to feel slow. The compounding comes after.
3. Mentorship is the multiplier
Pairing non-technical participants with technically proficient mentors removes the fear of failure and accelerates learning. The mentor doesn’t build for them. They provide a safety net.
4. Build something real
Requiring working prototypes with code repos and reference architectures (not slides) forces deep engagement with the tools. You can’t fake your way through a live demo. This is what separates a hackathon from a training course.
5. Measure before and after
Before and after competency assessments make the impact visible and build the business case for expansion. Self-reported confidence is useful, but the shift from “limited” to “extensive” hands-on experience is what matters.
6. Make it replicable
A well-documented playbook (participant guidelines, evaluation rubrics, mentor pairing frameworks, environment setup guides) turns a one-time event into a scalable program.
7. Create psychological safety first
When people aren’t afraid to fail, they build things they never thought possible. The winning team cited “learning over winning” as their top principle. Every team that thrived established trust before code.
Get started
The playbook, evaluation rubrics, and environment setup guides are available for teams looking to replicate this model. Reach out to one of the authors to learn more about bringing this framework to your organization.
Learn more about Amazon Bedrock | Kiro IDE | Strands Agents SDK