A general-purpose AI agent can be pointed at a B&R Automation Studio project and start working. No plugin, no adapter, no special build. B&R’s text-based format has been here for years. What’s new is what that format enables now that agents exist.
I want to walk through what agentic engineering actually means in this context, why the B&R platform is well-suited to it, where the limits are, and how we’re working to push those limits.
What “agentic” actually changes
The first wave of AI coding tools were autocomplete style. You typed, the model suggested. The driver was you, always. The model contributed a line at a time.
Agentic tools take tasks. You describe a goal: review this function block, propose a fix for issue 1247, generate a POU that meets this specification. The agent then moves through the project on its own. It opens files, follows references, reads configuration, applies edits, runs the build, checks the result, iterates if needed.
That shift has a practical implication. An autocomplete model only needs to see the line you’re typing and a bit of surrounding context. An agent needs to navigate. It needs to open files, follow symbols, understand dependencies. If it can’t do that, it can’t function as an agent.
So the question becomes: can the agent actually read your project?
Why text-based projects matter
An Automation Studio project is text. Source code in IEC 61131-3 languages, hardware configuration, library declarations, build settings, all of it stored as text files in a directory tree. There’s no opaque binary blob requiring a vendor tool to crack open.
For a general-purpose AI agent, this is the same situation it encounters with any modern software codebase. The agent uses its standard approach: list files, read the relevant ones, grep for symbols, follow imports, propose edits as text changes. Nothing about the format requires special handling.
The knock-on effects are worth noticing. Git works. Diffs are readable line by line. Code review happens at the granularity software engineers expect. None of this is novel for software engineers, but for industrial automation it represents an alignment with the broader software ecosystem that has been a long time coming.
What the agent still doesn’t know
A general agent that can read your project can do quite a lot. It cannot, however, know B&R.
It doesn’t know the difference between mapp Motion and mapp Cockpit. It doesn’t know which library function handles axis homing in your runtime version. It doesn’t know the naming conventions your team standardized on three years ago. It doesn’t know which X20 module you mean when you say “the analog input card.”
This is the domain knowledge gap. It’s the same gap you’d face onboarding a smart software engineer who has never touched Automation Studio. They can code, they can reason about control systems, they need to learn B&R.
For a human engineer, the path is the Automation Studio help system, the B&R Community forums, internal documentation, and time with experienced colleagues. For an agent, the path needs to be the same sources, exposed in a way the agent can call.
MCP as the domain knowledge bridge
The Model Context Protocol (MCP) is an open standard for giving AI agents access to external tools and data. An MCP server exposes capabilities; the agent calls them when relevant.
We’ve been building open source MCP servers to close the B&R domain knowledge gap:
-
as-help-mcp gives agents structured access to the Automation Studio help system. The agent can look up function block signatures, library descriptions, and configuration details on demand.
-
br-community-mcp gives agents access to the B&R Community knowledge base. When the agent encounters something it doesn’t recognize, it can search the community the way an engineer would.
The shape of the approach is worth noticing. The general-purpose agent stays general-purpose. The B&R knowledge stays where it already lives, in the help system and the community. MCP is the layer that connects them.
These servers are open source. Anyone can pick them up and point any MCP-compatible agent at them. The same servers we use internally.
Project-level instructions
Even with MCP closing the B&R-wide knowledge gap, your project has its own particularities. Team naming conventions. Internal library wrappers. Function blocks that are load-bearing for reasons not visible in the code. Decisio0ns made years ago that the codebase itself doesn’t explain.
Most agent tools now read a project-level instruction file when they start work. The conventions vary slightly (AGENTS.md, CLAUDE.md, .github/copilot-instructions.md, others), but the idea is the same: a markdown file checked into the project that tells the agent what it should know.
A useful instruction file for a B&R project might cover:
-
Naming and structuring conventions the team has standardized on
-
Libraries and modules in use, and which to prefer for new code
-
Areas of the codebase sensitive to change
-
Patterns that look unusual but are intentional
You write it once. Every engineer’s agent picks it up. The tacit knowledge that used to live in onboarding conversations becomes part of how the agent operates by default.
What this enables
With the project format readable and the domain knowledge bridged, real workflows become practical:
- Code review across an entire Automation Studio project, agent-driven, catching issues humans easily miss at scale
- Boilerplate generation from specification, with the agent following project conventions because it can actually see them
- Onboarding for engineers new to a codebase, with the agent answering “what does this POU do, what calls it, where else is this pattern used”
- Routine refactoring and consistency enforcement across files
- Analysis and debugging of complex issues
- Research and planning via official documentation
None of these are hypothetical. They’re things engineers are doing today, with general-purpose agents and the MCP servers above. What’s still being worked out is the rhythm: when to invoke the agent, how much autonomy to give it on which kinds of tasks, how to review its work effectively, how to fit it into the engineering process without creating new friction.
Where this is going
We’re early. The pieces work, the practice is forming. There’s plenty to learn about where agents are strong, where they get confused, how to structure a project so they navigate it well, and how to combine their throughput with the engineering judgment that doesn’t go away.
If you’ve been experimenting with AI agents on automation projects, I’d be interested in hearing what’s worked and what hasn’t. If you haven’t started yet, the entry barrier is lower than it might appear. The MCP servers are public. The agent tooling is general-purpose. The project you’re already working on is ready.
