Hello, this is Hamamoto from TIMEWELL.
I have been running a series called "Management on the Assumption of AI Agents". The first installment dealt with the stance leadership has to take, and the second laid out the three strategic options: hire, acquire, or develop. This time I am diving into the option that is the least glamorous and yet the one most companies will end up choosing — develop.
Hiring is fast, but assembling AI engineers at twenty million yen a year is realistically only possible for the largest firms. Acquiring depends on how much capital you can put on the table. What is left is to grow the AI-capable people you already employ. The catch is that "development" is also the easiest area in which to fool yourself. Order a training program, count completion rates, hand out certificates, and you can convincingly act as if something happened. I have watched this pattern play out across the industry more times than I can count.
Let me state the premise of this article up front. Development programs that stop at training will almost certainly fail. If you are serious about running a business on the back of one hundred or one thousand agents, you have no realistic option other than switching to in-the-job development that is wired into actual work. The rest of this piece breaks that down into six sections.
"We sent people to AI training" is not a development strategy
Let me start with the numbers. According to a February 2026 report by Josh Bersin, the corporate learning market has grown to roughly four hundred billion dollars, while multiple studies show that only around 5 percent of companies that have rolled generative AI into production are actually getting a return commensurate with their investment[^1][^4]. In other words, 95 percent are failing. The figure is shocking on paper, and entirely believable if you spend any time on the ground.
Why does this happen? The reason is simple: training and work are disconnected. Employees take thirty hours of e-learning, pass a quiz, get a certificate. The activity is logged. But come Monday morning the team is back in Excel and email. They know what AI can do, but they no longer have the energy to map it onto their day job. That is the typical fate of an AI training program in a Japanese company.
The problem is not the motivation of the participants. It is the program design. Because the training is separated from the work in time and in space, the question of "where do I actually use this skill?" gets pushed onto each individual. The most motivated 10 percent will figure it out. The remaining 90 percent get pulled back into business as usual. From a leadership viewpoint, ninety percent of the training spend is wasted. PwC Japan's research recommends an "accompanied OJT model that gradually transfers ownership and ends with the team running on its own"[^5]; designing training as a self-contained classroom event is, frankly, behind the times.
Honestly, when I hear a leadership team saying "we are investing in AI" while their actual move is just sending employees to a course, I have mixed feelings. Most of the time, what really happened is that the HR training budget shifted to a vendor. If you are serious about development, you have to redesign the program from day one so that training dissolves into the work itself. The next sections describe what that looks like.
Design the skills you need to grow as four tiers
The phrase "AI-capable talent" is so convenient that it can become hollow. In my own framing, the skills you need to grow break down into four tiers, from bottom to top: prompting basics, building your own Skills, agent design, and internal rollout.
Tier 1 is prompting basics: being able to give Claude a clear instruction, review its output, and run an improvement loop. This is the bar you want to set for almost every employee. Roughly twenty to forty hours of practical use is enough to get there. Tier 2 is building Skills: writing your own reusable instructions, in the style of Claude Code Skills, so that AI repeats a procedure on your behalf. Anthropic's Skills feature became one of the dominant community topics by March 2026[^3][^6], and one Fortune 500 company has reportedly built more than two hundred internal Skills, tripling the productivity of its junior engineers.
Tier 3 is agent design: stitching multiple Skills, MCP connectors, and external APIs into a single agent that can run an entire business process autonomously. This is what "multi-agent orchestration", as IBM Think and Salesforce Agentforce describe it, really means. People who can build at this level are rare; in Japanese companies, my gut feeling is that there is roughly one of them per thousand employees. Tier 4 is internal rollout: distributing the agents you build inside the organization, getting other people to use them, putting operational rules in place, and growing a community around it. This is much more about internal politics and organizational design than engineering.
Why split it into four tiers? Because companies that try to grow only the top tiers fail. You hire an expensive data scientist, but there is no Tier 1 or Tier 2 to support them, so they end up isolated. Or you have generous full-staff training but no path through to Tiers 3 and 4. When you design a development program, you should arrange these four tiers as a pyramid and set explicit headcount targets — for example, "by next year, fifty Tier 2 people, ten Tier 3 people, and three Tier 4 people". As long as you operate with a vague KPI like "raising the AI literacy of all employees", your organizational AI capability will not grow.
Looking for AI training and consulting?
Learn about WARP training programs and consulting services in our materials.
Building in-the-job development
Once you have defined the skill tiers, the next question is how to teach them. As I argued earlier, treating training as a standalone event almost never works. The cases I see succeed in the field share a single, very simple property: they explicitly allocate 20 to 30 percent of paid working time to "AI implementation".
In concrete terms, this means putting an AI block on Friday afternoon (or whichever slot you pick) on the calendar of everyone in scope. It is critical that this is not "training time" but "time to replace your own work with AI". The accompanied OJT used by NTT Data Group and BrainPad, and SIGNATE Cloud's internal contest format, all share the same principle: AI skills are practiced inside working hours, anchored to real work[^4]. Lectures are a supporting line; the main event is solving an actual operational problem.
This setup needs senior AI talent to act as facilitators. A realistic span is one Tier 3 person mentoring four to five mentees. The format is group OJT rather than 1:1, so skills propagate. Each member shares weekly what they shipped and where they got stuck, and the senior reviews code and prompt design. When we support an enterprise's AI in-housing, the first sixty days are spent almost entirely on standing up this structure. You will get more bang for your buck from one senior mentor and a protected OJT slot than from a hundred hours of training videos.
A side note: when I propose this to Japanese companies, the rule that meets the strongest resistance is "set aside 20 percent of working time for implementation". In the short term, that is 20 percent of existing work that will not get done. I do not back down. The reason is obvious: once you replace that 20 percent with AI, you typically get back 60 to 80 percent improvement on the rest. The first three months are in the red, but by month six the program flips to black. Whether leadership can make that call essentially decides more than half of the program's outcome.
Operationalizing skill sharing (Skills.md, connectors, an internal library)
Once people start building agents and Skills inside an in-the-job program, the next bottleneck is that those assets exist only on the individual's laptop. Person A's excellent meeting-summary Skill never reaches Person B; everyone reinvents the same thing, and across the whole company you waste enormous time. The fix is to operationalize skill sharing.
There are three things you need at minimum. First, a central repository for Skills.md: a private GitHub repo in which all employee-created Skills are aggregated as Markdown and made pullable from a Plugin Marketplace. The Zenn implementation post[^6] documents how to register your own GitHub as a Claude Code internal Marketplace. Second, central management of connectors (MCP servers). According to Anthropic's official documentation, administrators on the Enterprise plan can control allowed connectors via an allowlist. Connections to Google Workspace, Microsoft 365, your own CRM, and similar systems should be approved and audited centrally by IT. Without this, security incidents inevitably emerge from improvised connections in the field.
Third, documentation of the internal library. A single page that lists each Skill, what it is for, who built it, when it was last updated, and how often it is used. Whether or not this exists drastically changes how often you accidentally rebuild the same Skill. In my own deployments, we put a "Skill ledger" in Notion or a small in-house web app, and use a Monday morning ritual to surface the new and updated Skills of the week. It is unglamorous, but it works.
In one company we are supporting through WARP, six months after introducing this system the number of Skills grew from three to one hundred eighty, and monthly citation counts (the number of times a Skill was invoked by an employee) crossed ten thousand. The crucial point is not that someone forced this from the top, but that once "how often my Skill is being used" became visible in the ledger, employees started improving on their own. Operationalizing is not the same as forcing — it is designing a system in which voluntary effort keeps compounding.
Running the dual axis of top-down and bottom-up
Once a development program is on track, the next predictable failure mode shows up: the first few months are powered by enthusiasm, then six months in, momentum stalls. I have seen this enough times to be confident the structural cause is having only top-down or only bottom-up, never both.
What you must own from the top is weekly KPI monitoring. Put AI development progress on the regular agenda of the executive team. Specifically, review five indicators every week: number of Skills, citation count (total times a Skill was invoked), number of automated tasks, working hours saved, and headcount progression at Tiers 2 through 4. In OBC's well-known company-wide rollout of Microsoft 365 Copilot, executives explicitly tracked "every employee uses AI as a matter of course" as a KPI, which the case study cites as a success factor[^7]. The numbers leadership watches are the numbers the field will move.
What you need from the bottom is employee-led communities and events. Hold a monthly "AI Implementation Showcase" in which members from each department demo the agents they built. Award the best ones with a CEO prize or a cash bounty. Create dedicated channels — ai-skills, ai-agents — on Slack or Teams where questions and tips flow as part of daily life. The HR department should not run this community. It only stays alive because Tier 3 individual contributors run it, and that is where the energy comes from.
I called this a dual axis, but more precisely: top-down owns "discipline of numbers" and bottom-up owns "cultivation of culture". Lose either and the program dies. Top-down alone turns into number theatre; bottom-up alone is fun for the enthusiasts and ends there. Leadership has to respect the community while watching the numbers; the community has to understand the numbers while running itself. Not many companies can hold both, which is exactly why this is where competitive distance is created.
Designing a 90-day program you can launch now
To close, here is a 90-day roadmap aimed at executives and HR leaders who want to start moving. A concrete sequence you can act on tomorrow is more useful than another idealized treatise.
In the first 30 days, inventory the actual work and define skill tiers. Before ordering any training content, map the work in the target departments at the level of a single day, and pick three to five tasks with the largest room for AI substitution. In parallel, write down your own version of the four-tier model and count today's headcount at each tier. In most cases, Tier 3 and Tier 4 are at zero. Honestly accepting that fact is the starting line.
Days 31 to 60 are about securing Tier 3 talent and standing up a pilot team. Having even one Tier 3 person internally is something of a miracle; if you have none, the practical decision is whether to bring in an external partner like WARP for accompanied delivery, or to hire ready-made talent. Form a pilot team of five to ten people and block 20 to 30 percent of their time as an AI implementation slot. Build the three-piece set: central Skills repository, internal Marketplace, and Skill ledger. If you are also rolling out an enterprise AI platform like ZEROCK, integrating knowledge and provisioning connectors in this same window meaningfully changes the acceleration after day 61.
Days 61 to 90 are about formally launching top-down KPIs and the bottom-up community. Make AI development KPIs a permanent agenda item in the executive meeting and review the five metrics every week. Open the dedicated Slack channel and run the first AI Implementation Showcase on day 90. By the end of these 90 days, if you have 20 to 50 Skills, 5 to 10 Tier 2 people, and 1 to 3 Tier 3 people, the program has effectively taken off.
At WARP, we offer a service that runs exactly this 90-day program with you. We deploy our own Tier 3 and Tier 4 people inside your company so that your members grow through OJT. Development is sometimes described as "a function you cannot outsource", and that is broadly true — but for the first 90 days specifically, having an embedded partner produces a dramatically faster ramp, which is the conclusion I have drawn from supporting more than twenty companies. If "Management on the assumption of AI agents" resonates with you, start by counting how many Tier 3 people you actually have. The number is probably smaller than you think. That is where the real work begins.
References
[^1]: New Research: How AI Transforms $400 Billion Of Corporate Learning – Josh Bersin (February 2026) [^2]: Huawei Unveils AI Talent Development Service Solution (March 2026) [^3]: agent-skills (GitHub – addyosmani) [^4]: Roadmap for Generative AI Adoption in 2026 – ExaWizards [^5]: "AI Talent" Development Approach Inside Companies – PwC Japan [^6]: How to share Claude Code Skills and Hooks internally – Zenn [^7]: OBC's effort to cultivate an AI-driven culture through company-wide Microsoft 365 Copilot deployment and in-house development – Microsoft Customer Stories