FDEs and Deployment Strategists: Connecting AI Engineering to Adoption

An AI project can have a capable model, a convincing prototype, and an enthusiastic sponsor while still struggling to enter daily use. The missing work often sits between technical implementation and the organization’s ability to adopt the result.

Tokyo AI’s Field CTO and FDE event, held on 26 May 2026, brought together practitioners from LayerX, Spacedata, OpenAI, Cognition, and Foundry Labs. Its programme offers a useful way to examine that work: who understands the problem, who changes the system, and who makes the change usable?

Start with responsibilities, then discuss titles

Forward Deployed Engineers work close to users and the conditions in which a system must operate. The event programme connects this role with customer discovery, system design, the transition from PoC to production, and feedback into product development.

The value of this proximity is that implementation and learning can happen together. A requirement that appears straightforward in a meeting may become ambiguous when someone uses it during a busy shift. An engineer who can observe that ambiguity and change the system has a shorter path to a useful solution.

But technical proximity does not automatically settle organizational questions. Someone still needs to agree on the problem’s priority, the people involved, the definition of success, and the changes required in existing work. Those responsibilities need explicit ownership, whether or not an organization uses a particular job title.

Deployment strategy connects the project to its operating context

Katsushige Kitazawa, CTO of Spacedata, presents Deployment Strategist work across alignment, scoping, setup, project steering, and engineering. His account places customer context throughout delivery rather than confining it to a requirements document at the beginning.

Alignment establishes the problem and expectations. Scoping turns that understanding into a tractable use case. Setup makes resources and communication available. Steering maintains the feedback loop as work progresses. Engineering then happens in contact with the actual activity the project is intended to improve.

These phases expose a familiar source of friction. A sponsor might value a faster reporting cycle, while the person preparing the report needs reliable access to scattered records and a way to handle exceptions. Both concerns are valid. The delivery challenge is to connect them in one system and one definition of useful progress.

Coding agents change the work without removing the handoffs

The programme included Masanori Onda’s account of FDE practice at LayerX and coding agents, and Shuhei Ishida’s discussion of coding-agent adoption. Akira Shibata joined the panel as Field CTO at Cognition, with Foundry Labs CTO Declan Clowry moderating.

That combination raises an important organizational question. If producing a technical change becomes easier, what determines whether it should be made? More implementation capacity increases the value of choosing the right scope and having a reliable path from user feedback to a reviewed change.

The distinction is useful when hiring, too. A team may need stronger hands-on integration, clearer use-case ownership, or better coordination across departments. Calling every gap an “FDE problem” can obscure the capability it actually needs.

Foundry’s perspective: follow an exception through a real workflow

Consider an illustrative inventory-planning assistant. A PoC recommends replenishment from a spreadsheet and produces plausible results. The deployment question is what happens when a supplier changes a delivery date, an item is being discontinued, or the recorded stock level is wrong.

The engineering work includes connecting the relevant systems, preserving the data behind each recommendation, and preventing duplicate or unauthorized orders. Deployment strategy includes agreeing who handles an uncertain recommendation, which existing approval remains, and how the planning team will work during a service interruption.

Those responsibilities are most effective when they meet around concrete cases. A planner rejects a recommendation because a promotion is ending. The team must determine whether the missing information should become a data field, a rule, a user confirmation, or a reason to stop. That decision is simultaneously a product, engineering, and operational question.

A sensible first release could prepare recommendations for one product category while planners retain ordering authority. Progress would be assessed through correction effort, exception resolution, and the share of recommendations that fit the business context. A broader rollout follows when the system and the team can handle the edge cases together.

This is the practical connection to Foundry’s FDE Excellence Programme. The capability worth developing is the ability to connect a business problem to working software, then remain close enough to improve it as the organization starts using it.

Sources and further reading

This article draws on the AI時代のField CTO・FDE programme and the talks identified above. Tokyo AI (TAI) connects researchers, engineers, and industry; explore Foundry Labs’ community work for more context.

Talk materials from Katsushige Kitazawa are available upon request. Please use our contact form and include the event title and speaker name.

Speaker profiles

恩田壮恭 / Masanori Onda. Lead FDE at LayerX. His talk covers FDE practices for enterprise AI. LinkedIn.

北澤克樹 / Katsushige Kitazawa. CTO of Spacedata and former Enterprise Lead Data Scientist at Palantir. LinkedIn.

石田修平 / Shuhei Ishida. Principal Solutions Architect at OpenAI, working on enterprise AI adoption. LinkedIn.

シバタアキラ / Akira Shibata. Field CTO at Cognition. His talk brings a field-engineering perspective to AI adoption. LinkedIn.

Declan Clowry. CTO of Foundry Labs and former Palantir FDE. He moderates the discussion. LinkedIn.

All articles