At its inaugural meeting, the Arrowfly AI Engineering Industry Board connected perspectives across engineering, manufacturing, healthcare and research to explore what it takes to turn AI’s potential into measurable value.
There are few investments in the current business environment that aren’t put through a rigorous vetting process. Cost, timing, footprint, fit, productivity, efficiency are all considered, but what a company really wants to discern is how much return on investment it can reasonably expect and how long will it take? The risk of making a poor decision on a major investment is so great that the process can take months, or in some cases, years.
But in the case of artificial intelligence (AI), things have changed. Companies are moving at light speed to implement what could be the most impactful technology since the dawn of the internet. This is because most of these variables are still relatively unknown, or so dependant on a company’s specific systems and architecture that they can’t be reliably forecast, and hey, your competitors are doing it so you can’t get left behind, right?
Wrong. A company can be an early adopter of AI but still be left in the dust. An engineer can build a new AI-powered tool, a leadership team can commit to an ambitious AI strategy, and a manufacturer can give employees access to the latest models, but none of those actions answer the question that matters most: What will actually improve?
This is the question that ran through the inaugural Arrowfly AI Engineering Board meeting on September 24, 2026. The result was not a slate of predictions or a celebration of technology. It was a candid exploration of how to choose worthwhile problems, preserve engineering knowledge, validate results and build trust, all while keeping pace with the technology and your competition.
The board’s industry members span a broad cross-section of manufacturing, enterprise technology, energy, and healthcare. This type of cross-industry conversation is where the true value of the board emerged, as participants built on each other’s observations and experiences. As the discussion went along, a practical theme took shape. Success depends less on using AI everywhere than on understanding where it belongs.
The biggest change is cultural
Much of the attention surrounding AI focuses on advances in models and software. The board’s opening discussion highlighted an equally consequential shift: People are becoming more willing to change how they work.
The discussion highlighted a measured emphasis on AI used alongside human expertise and critical thinking—not AI as a requirement for innovation or replacement for workers. Organizations need people willing to explore new possibilities, but they also need experienced practitioners capable of judging whether those possibilities are useful.
From individual tools to connected workflows
Another shift involves what organizations expect AI to do.
The conversation described growing interest in moving beyond standalone chat interfaces toward tools that connect engineering systems and coordinate work across disciplines, as can be seen in the advent of agentic AI. Instead of asking only what a model can generate, organizations are asking how AI can operate within the workflows they already depend on.
Protocols such as the Model Context Protocol (MCP) are opening conversations about exposing existing software capabilities as tools that AI agents can use. In engineering, that can mean connecting natural-language instructions, code generation and workflow scripting to tasks such as creating or modifying design geometry.
The opportunity extends beyond individual design tasks. Board members described demand for three related capabilities:
- Reducing routine work so specialists can focus on engineering,
- bringing context to information distributed across many systems,
- orchestrating processes across those systems.
Those ambitions encounter practical constraints: Legacy equipment, limited infrastructure and vendor ecosystems that are difficult to connect are common parts of most operating environments. The question is not simply whether a new AI capability works. It’s whether that capability can work with the equipment and systems already in place.
Choose the problem before the tool
With new models and tools arriving almost daily, experimentation can easily become a succession of trials without a clear destination.
The board’s discussion brought the focus back to basic questions: Who is the intended user? What are they trying to accomplish? Where is the bottleneck? Is the objective to assist a person, automate a task or accelerate a process?
If you noticed these are not new questions, you’re not alone. Similar questions formed the backbone of lean manufacturing and Six Sigma for decades and they are equally applicable to AI projects. Answering them before starting a pilot or trial establishes what success should look like before implementation begins.
Balance creative freedom with business discipline
The ability to build tools quickly creates opportunities for employees to improve their own work. It also creates a management challenge because an application that benefits one person or one small team may not justify broader investment.
The discussion traced a progression from widespread experimentation to closer scrutiny of token consumption and costs, followed by demands for a clearer use case before resources are committed.
Requiring justification on a project can feel restrictive for engineers who are still discovering what the technology makes possible. But without a connection to business needs, activity can grow faster than demonstrated value.
One approach to address this is a lightweight review in which employees describe the intended application and its purpose before development proceeds. The goal would be to make deliberate choices without putting every experiment through a lengthy approval cycle.
Resources extend beyond AI usage costs. Organizations also need people to develop and test support applications. Even when promising opportunities are plentiful, the capacity to pursue them may not be—particularly when the same engineers are expected to maintain their existing responsibilities.
Choosing what not to pursue becomes part of making progress (also not a new concept).
Make early wins narrow, measurable and credible
Starting small is a practical way to manage both uncertainty and limited resources.
The discussion included applications involving capital management, project funding and scheduling—areas where historical information can support tracking and prediction. Testing new systems while continuing manual tracking provides a way to compare results and establish confidence before expanding.
That approach connects implementation to evidence. A project can demonstrate early in the process whether a system will produce the intended result, rather than relying on the appeal of the technology itself.
The discussion also challenged expectations that complex engineering applications should work immediately out of the box.
Broad-use tools may allow users to find their own applications with relatively little setup. However, specialist tools can require much more configuration and context before becoming productive. Success with a simple task does not establish that the same approach will succeed with a much more demanding one. This makes implementation effort and expectation-setting a big part of the value equation. Going deeper on a defined problem may accomplish more than testing many applications superficially.
Data readiness starts with the intended use
The discussion moved quickly beyond the question of whether an organization has enough data (you probably do), to whether that data is clean enough and trustworthy enough (it’s probably not, at least not right away) to make a project work.
Engineering businesses have decades of designs, revisions, incomplete projects and historical records—there’s often plenty of data. The harder question is which data is appropriate for the task.
Is an older design still relevant? Which version is correct? Was a record completed? Does a dataset represent work that should inform future decisions?
These questions make data selection an engineering judgment, not merely a retrieval exercise.
Validation matters as well. Access to information does not establish its accuracy, and a functioning system does not establish that it delivers the intended result. Testing must address both.
At the same time, board members cautioned against making data preparation so expansive that it prevents useful work from beginning. Starting with a particular application (remember, start with the problem, not the technology) can narrow the information required and make data and project readiness a more manageable question.
A design-review application, for example, may begin with a defined set of checklists rather than an attempt to organize every engineering record. A simulation application may have identifiable reference datasets that provide a practical starting point.
The distinction is between preparing data for a purpose and trying to resolve every data problem before pursuing any purpose at all.
Preserve the reasoning, not just the record
As participants expanded on data readiness, the conversation quickly turned to one of the meeting’s most consequential questions:
What knowledge never makes it into the record?
A research dataset may contain numbers but omits the observations, conditions and context needed to interpret them. Those details may seem obvious to the person conducting the work but are indispensable to someone trying to reuse it to train an AI agent.
The pressure to innovate quickly can compound the problem. Faster documentation—or documentation generated with AI—does not necessarily preserve the details you need.
That concern connected with a framework raised elsewhere in the discussion: Artifacts, dependencies and decisions.
Artifacts are the objects and their metadata. Dependencies describe how those objects relate—for example, how a part connects to a requirement or how a requirement connects to a test. Decisions explain why a particular course was chosen.
Each adds a different kind of context. Knowing what exists is not the same as understanding how it connects to other work, and neither necessarily explains the reasoning behind it.
Decision knowledge can be particularly difficult to recover because it is distributed across emails, meetings and design reviews, rather than neatly organized spreadsheets.
For organizations hoping to use AI to draw on accumulated engineering experience, the implication is significant: Making records accessible is only part of the task. Preserving the relationships and reasoning that make them meaningful is imperative.
Old school meets new school
One recommendation brought another established, familiar method into the data-readiness conversation: Overlay data flows on a value-stream map.
Value stream mapping is an established lean methodology that provides a view of how work moves through a facility. Adding the data stream helps reveal what information passes between steps and how those hand-offs describe and support the process.
Mapping process and data together offers a more concrete starting point for those conversations. It grounds the investigation in actual work rather than treating data integration as a separate, abstract undertaking.
Physical AI brings safety to the foreground
As AI moves into robots and other physical systems, the consequences of its behavior become much more tangible.
The board’s discussion emphasized questions of deterministic safety, system latency, integration and governance. A robot’s ability to execute a task is only one part of deciding whether it can operate safely and effectively around people and other equipment.
Similar concerns apply to engineering tools used to develop products that can affect people’s lives. Probabilistic outputs require appropriate guardrails and validation; generating an answer is not the same as establishing that the answer is suitable for a consequential decision.
These considerations place safety and governance inside the engineering problem itself.
They also reinforce the importance of human expertise. Across research, industrial applications and physical AI, the discussion repeatedly returned to the need for people who can assess the work, recognize limitations and determine what evidence is sufficient.
Bringing it all together
The inaugural meeting’s strength was not that every participant described the same experience. It was that different experiences combined to form the basis of concrete actions that can directly improve results.
Enthusiasm for connected engineering workflows sat alongside concerns about legacy infrastructure. The freedom to build new applications was considered alongside the resources required to support them. Calls for better data access developed into questions about documentation, relationships and decision rationale.
For readers navigating their own AI decisions, the meeting offered practical starting points:
- Define the problem precisely
- Understand what information the application requires
- Preserve the context that gives that information meaning
- Test the result against the intended outcome
- Use evidence, not novelty, to guide expansion
For the AI Engineering Industry Board, it demonstrated the value of a cross-industry forum where ideas can be examined, challenged and incubated by people confronting different versions of the same underlying problems.
The opportunity is not simply to keep up with what AI can do. It’s to help engineers make better decisions about what to do with it.
For more information, news, and research on AI for engineers, including the AI Engineering Board, and the prestigious AI for Engineers live, in-person event, visit our AI for Engineers website.
