Agentic Engineering: Generative AI In Structural Applications
Interview with Sergey Pigach
Following is an interview with Sergey Pigach of CORE at Thornton Tomasetti who’s previous presentation at CDFAM in NYC really set the bar for how advanced an architectural engineering firm can be in the adoption of Agentic AI built on a strong foundation of computational design systems developed over years of in-house and client feedback.
Everyone I spoke to after the event from the mechanical engineering, automotive and aerospace sectors were shocked by the maturity of their computational design frameworks and understandings that allowed them to explore emerging AI tools with confidence and rigor.
Sergey will be back in DC this year, so I asked him for an update on what they have been exploring over the past year, and what we can expect to see at CDFAM in DC.
You blew people’s minds at CDFAM in New York last year. For anyone who missed that session, how would you describe CORE studio’s work, and what has shifted in the year since that brings you back with agentic systems as the focus?
Thank you, you are entirely too kind. I have to say, I thoroughly enjoyed presenting at CDFAM last year, and I am very glad to be invited back.
In a nutshell, CORE studio is the R&D arm of Thornton Tomasetti, and we are focused primarily on developing computational tools and workflows that benefit our engineers and the broader AEC community. CORE consists of about 40 people split into a number of different verticals, such as CORE Modeling, Applications Development, Knowledge & Data, and CORE AI, just to name a few.
My presentation last year talked about the work of our AI team on creating a library of machine-learning-powered tools for structural analysis and design.
The goal of this multi-year effort is to let our engineers move really fast in the early stages of a project and iterate rapidly without being bogged down by clunky commercial software.
I hinted at the fact that creating structural design APIs opened some interesting opportunities for agentic workflows with MCP and showed some of our early tests, but, for the most part, my presentation was about classical ML tools that we actually use in production.
This time around, I am, in fact, focusing almost entirely on agentic systems, which we are pursuing quite aggressively at the moment.
I’ll say upfront that we are still not entirely comfortable with employing fully autonomous agentic workflows on real projects, so everything I’ll be sharing still exists under the umbrella of research and development. But the ultimate goal is, of course, to find safe and practical ways of using these systems in our real work.
Either way, agentic AI in structural engineering is something we have spent a significant amount of time working on and thinking about, so I am very excited to show what we have developed over the past eight months, even though most of these tools are still very much in Alpha.
The biggest change since last year probably occurred not in the realm of engineering, but in how CORE studio builds software.
Introduction of agentic coding tools like Codex and Claude Code really turned the way we think about application development on its head. We now have small teams taking on ambitious projects that would not have been feasible just six months ago. I, personally, no longer make UI wireframes: instead, I build a quick prototype, get it to look exactly how I like it, and then use that as the jumping-off point for future discussions.
Generally, I find myself doing a lot more thinking and a lot less typing. And, of course, because of how fast we are now able to produce software, the conversations about software architecture, continuous integration, security, product, and user acceptance take the front stage. CORE is not the only group at TT that is experiencing this shift, either. We are also seeing the emergence of what we are calling “citizen coding,” where engineers throughout the company who previously did not know how to program are suddenly building personalized automations and full-fledged application suites. This is both exciting and terrifying from the compliance and security standpoint, so we have been working closely with our IT in order to give our citizen coders the resources and the training they need to do this safely. But this is a discussion for another time.
Video Courtesy of Marijn Luijmes
The classical ML tools CORE studio built over the past decade rest on a computational design foundation, the systems thinking and structured approach that makes applied AI possible in the first place. How much does the viability of agentic systems depend on that groundwork already being in place, rather than on the agents themselves?
This is an excellent question that, frankly, keeps me up at night. It is uncomfortable to ponder because essentially what you’re asking is “how much of the agent’s usefulness to your business lies in your proprietary tooling and domain expertise vs. comes off-the-shelf from OpenAI, Anthropic, and other frontier labs”. In other words, how much do you actually bring to the table in the world where intelligence is becoming increasingly more general and abundant?
I’m sure my answer will age horribly, but at least as of July 2026, the harness and the tools available to the agent are more important than ever. And this all comes down to the stochastic nature of Large Language Models, which makes their output very difficult to audit.
The nice thing about classical ML, algorithmic design, and traditional computational workflows is that they give stable, deterministic answers. Sure, all software can have bugs, but at least those bugs can be identified and fixed.
Conventional systems are predictable, and therefore, we have learned to trust them. And this is something AI labs also understand, so they’ve been spending a good portion of their post-training compute on teaching models to be good at tool calling and to express solutions for complex problems in the language of deterministic executable code if no pre-built tool is available.
So when you ask your favorite chatbot to design you a concrete bay from scratch, it will happily write a disposable solver, run it in its sandbox, and give you the computed results. Can you trust the numbers? We’ll get to that in a moment. But, in general, for completing random, one-off tasks, this approach works pretty well. Forcing models to build disposable deterministic tools on the fly really helps improve accuracy and reduce hallucinations. So an off-the-shelf agent with no specialized tools can certainly rely on its vast knowledge of numerous disciplines to be useful for domain-specific work.
But once you start building dedicated, specialized agents that are integrated into production workflows, reinventing the wheel every single time no longer makes sense.
First of all, letting the agent rebuild all of its tooling on every invocation is slow and wasteful (someone will have to pay for those tokens after all). But even if you’re not too concerned with inference costs, there is no good way to audit the agent’s solution.
As an inherently stochastic system, an agent can make inconsistent assumptions, forget important bits of context, and simply make mistakes as it scribbles a solution in its scratch pad. This is why it is still valuable to build vetted, proven, auditable traditional tools that the agent can use when needed. And the fact that CORE already has a full library of ML-based and conventional engineering APIs makes us very well positioned for this agentic transition. So, at the end of the day, it is the combination of trusted, deterministic tools with adaptable, broadly intelligent AI agents that makes these systems so powerful for real-life work.
I mentioned trusting the numbers provided by AI-powered disposable software. Obviously, as a structural engineering firm, we require every calculation and design decision to go through a rigorous QA/QC process, so we can never blindly trust the output of any workflow, whether it is deterministic or stochastic. However, we did want to get a sense for how close current AI models are to being able to solve structural engineering problems without any industry-specific tools. So we created a benchmark called MOMENT eval, which I will talk about in my presentation.
It uses a very simple harness with just two tools. One is a calculator, the other is a sandboxed Python environment with no internet access that the models can use to express their engineering solutions in code. I won’t spoil anything, but the results we’ve got from this benchmark are… unsettling. Structural engineering is a verifiable domain, and modern-day LLMs are really good at solving those types of problems.
The presentation covers multi-agent collaboration over the A2A protocol alongside your own work connecting LLMs to CAD through MCP. How do those pieces fit together in a single workflow, and where does each one carry the load?
A2A and MCP are complementary. MCP is a standard way for agents to interact with tools, and A2A is a standard way for agents to interact with each other. So, at a high level, you can have multiple agents with access to specific skills, tools, and data “collaborating” with one another to solve the task at hand. We’ve done a bunch of R&D exploring the protocol and building simple agentic systems as a proof of concept – I will show some of this as well. But thinking about the future, we also toyed with the idea of different practices within TT spinning up their own A2A infrastructure, advertising services to each other, and dynamically delegating tasks. What is great about both MCP and A2A is that the types of payloads that can be exchanged using these protocols are pretty open-ended. You are not constrained to only, say, text or images – you can exchange binary data as well. For the AEC crowd, this means that one agent can generate, say, a CAD file and share it with some other agent.
But to me personally, having workflows organically emerge from agents self-organizing into chains of delegation is the most exciting prospect. To be clear, we have not achieved this yet at TT, partially because there are many prerequisites in the realm of data governance, security, infrastructure, and product that we have to get right before letting agents loose inside our organization. But also because the A2A ecosystem is still incredibly young and we are spending most of our time exploring, experimenting, and, frankly, having fun with it before committing to a single strategic vision.
When an agentic system orchestrates a multi-stage structural workflow, how does data move between the agents, the ML tools, and the CAD environment? How do you validate the performance of each, and where in that chain does an engineer stay in the loop?
One of the most important aspects of successfully utilizing agentic systems for mission-critical applications is observability. And this doesn’t mean that an engineer manually reviews every tool call and every artifact – otherwise, what’s the point of automating parts of your process if you’re then forced to manually approve every step.
This just means that when issues arise, we as an organization have access to the full audit trail so that we can figure out what went wrong and implement the necessary changes quickly.
Even in normal operation, whenever an engineer’s intuition tells them that something feels off and they want to investigate how an agent arrived at a particular answer, they should be able to do this easily. And the final line of defense is always QA/QC. It doesn’t matter whether a drawing or a calculation has been hand-crafted by a human, generated by a computational workflow, or conjured up by an LLM – multiple people will be looking at it carefully before it gets anywhere near an official drawing set.
We’ve also been experimenting with adding agents to spaces where engineers collaborate and solve problems, like a public Slack channel, for example.
There is something very interesting about having an agent be part of a conversation between multiple people, as opposed to interacting with a single user one-on-one. The work happens as it normally would: questions are asked, issues are raised, and files and markups are shared. Whenever someone needs a quick calculation, a lookup, or a second opinion, they can just @mention an AI agent, who will automatically have the conversation added to its context and doesn’t need to be caught up. And the best part is that there are enough adults in the room to call out mistakes or say, “This can’t be right.” So, in short, an engineer is in the loop whenever the product of an agentic workflow is about to become the basis for some decision moving forward.
The responsibility and the liability for the final call still lie with the person; agents just let us get there faster.
Enterprise integration raises safety, security, and compliance questions that a standalone tool does not. What have those concerns required you to build or constrain, and how much of that work sits in Cortex?
Building enterprise software in the age of agentic AI is both a blessing and a curse. On the one hand, we have all these amazing coding tools that are very good at static code analysis, testing, identifying vulnerabilities, and unearthing obscure bugs. Of course, we still do manual reviews, internal red teaming in collaboration with our IT, and even external penetration tests. But all of them take a significant amount of time and effort, so coding agents have been a fantastic way to quickly get a second pair of eyes on whatever pull request you’re about to merge. But the flip side of this is that with very little effort and a bit of ingenuity, the same agentic tools can be used offensively by bad actors.
I had the pleasure of attending the AWS AI Security Symposium in NY earlier this year. I believe it was Thomas Mazzaferro, Chief Data Officer at Cyera, who said in his presentation that “AI is going to nibble on every endpoint out there,” which I think is an excellent way of putting it.
And what’s even scarier is that in the past, the amount of damage a bad actor could cause to an organization was very much constrained by their skill level and the amount of resources (essentially, money and time) they had at their disposal. Now, any wannabe hacktivist can vibe code their way to becoming an Advanced Persistent Threat. I’m exaggerating, of course, but the core problem remains the same: our traditional security controls have not been designed to respond to this onslaught. If you don’t believe me, ask GitHub, NPM, and a number of other high-profile enterprises that have been having a pretty rough time lately.
And these are just external threats. The call is also coming from inside the house. The moment you introduce an agentic system into your enterprise environment, you have to change the way you think about the threat profile.
This agent is not just another piece of software that can have vulnerabilities in need of patching. A much better mental model for thinking about agentic systems in a security context is an insider threat. What you have is an intelligent system that lives within your trust boundary, has legitimate access to your internal systems, can take actions, and make its own decisions. If this system is compromised through memory poisoning or a prompt injection, or if it simply decides to take drastic action because the underlying LLM is a little misaligned, it can do a lot of damage. And the type of threat it poses is a lot closer to a disgruntled employee than an unpatched bug in a CAD product.
AWS actually introduced the concept of what they call “the lethal trifecta.” If your enterprise has an agent that 1. has access to confidential data, 2. ingests new content unfiltered, and 3. can communicate with the outside world (e.g., send emails to customers), then you are just asking for trouble.
Obviously, we take this threat model very seriously. Every agent we design and integrate with our internal systems follows zero-trust architecture principles. Agents have distinct machine identities with the least amount of privileges required for them to do their work. We treat natural language as executable code: before a piece of text touches an LLM, it passes through a series of guardrails and content moderation filters. We scan model outputs as well for leaked credentials and personal information.
Observability through proper logging and alert systems is also part of the picture. So, the security piece for us is less about building a single product that “makes us secure,” but about designing new systems in accordance with best security practices while also hardening our existing stack. Cortex is certainly part of the equation; IT is actually red teaming it as we speak. But there is really no single silver bullet. There are alien creatures with legitimate access sitting on our security boundaries, and we have to act accordingly.
One new thing we are building to respond to the challenges of agentic AI is our own LLM inference stack that we are nicknaming Stargate (yes, we are that nerdy). It is meant to help us address the data governance problem. Thornton Tomasetti works on many confidential projects, and we treat information security very seriously. At the moment, we use public inference APIs for our agentic experiments, which is fine, because none of this is allowed to touch real projects quite yet. But eventually, we will need a secure inference infrastructure that allows us to stay compliant while using AI on project data. So this is another piece we have to finish building before deploying agents in production.
You frame this as part of a larger shift in the relationship between engineers and their tools. What do you want this audience to take from your presentation, and what are you hoping to hear back from them at CDFAM DC?
Not to sound overly dramatic, but the last few years have really felt like we are all living inside a history book (which is never an enviable position to be in, by the way).
I will hardly be the first one to point out how rapidly things are changing. I think what we have to prepare for as an industry is that many of our assumptions will not survive this transition.
The way we approach projects, the way we assess risks, and the way we prioritize effort will all change one way or another, so it’s important to stay on your toes. And the truth is that we’re all figuring this out and making it up as we go along.
No one has all the answers. So I am very excited to see how other professionals in the design space are approaching this AI transformation, and I hope to learn from their experiences as well.
