Bite Engineering

Brief

Structural engineers work across a stack of disconnected software every day: analysis models, calculation tools, spreadsheets, drawings, emails and messages. When a design request arrives, the engineer has to work out what needs to change, update every affected file, and maintain an audit trail of everything they did. This can take weeks to coordinate. The Building Safety Act 2022 has made this more time-consuming and high-stakes – it mandates a level of documentation that firms have to produce each time a design changes and brings extra scrutiny.

Bite was founded to solve this. It uses AI and automation to give engineers their time back while staying confidently compliant. The founding team built a v0.1 platform: an AI workspace that could connect to a firm's engineering tools, understand the project and design, and answer questions across a project archive. It covered a small part of the workflow, but held enough promise that two structural engineering firms were already using it.

Loomery was brought in to help Bite take the next step: expand the product to cover the end-to-end change workflow, while addressing critical user feedback on reliability and scalability.

Project in numbers

user feedback themes informed the new design

<20

Seconds from 90+ to process and understand files

~99%

files successfully processed (vs ~60%)

Getting into the problem

Diagram illustrating clear standards with four shapes at the top—a black triangle, green circle, red square, and purple pentagon—leading to a structured results grid showing the purple pentagon transformed into a green circle, then red square, and finally black triangle through a series of arrows.

Before any architectural decisions were made, the team ran a detailed analysis of real usage: session logs from active users, broken down by query type and outcome. The most common thing engineers were doing was searching for precedents; examples of how their firm had handled a similar problem on a past project. Retrieving drawings was close behind. Almost none of the usage was about external technical standards or library searches, which had shaped early assumptions about what the product should prioritise.

We also ran structured domain sessions with users to understand the actual workflow: what a structural engineer does with ETABS, AXISVM or Tekla Tedds, and how a change to a column's cross-section cascades through local slab models, steel calculations, drawings, and compliance records. That domain depth was essential groundwork before any decisions were made about what to build and in what order.

A clean slate on the architecture

Discovery produced a clear picture of what needed to change and why. The v0.1 platform had been built around a low-code orchestration tool that made the pipeline fast to prototype but hard to test, observe, or improve.

We opted to replace it with dedicated Python services, giving the engineering team full control over the ingestion and retrieval pipeline, a proper evaluation framework, and the ability to benchmark improvement systematically.

The v1 codebase would live in a single monorepo: one place to run, test, and deploy the full stack. A more reliable file-processing pipeline was built using Azure Service Bus and a collection of newly developed components to parse data, identify structural entities and design elements, and assess the impact of changes. This enabled scalable, parallel processing of files with robust error handling, replacing a previously sequential process that suffered from a number of reliability issues.

Modern AI-native workflows powered by frontier model APIs

Diagram of Bite's v0.1 ingestion: six file types — PDF, scan, markup, ETABS/TEDDS, XLSX and EML — all funnelling into one step that summarises every page with a single model, then chunks and embeds. Tagged slow, expensive, and loses numbers and dimensions.

Engineers send Bite a mix of file types: PDF drawings, scanned calculation sheets, hand-marked-up plans, software exports from tools like ETABS and Tedds, spreadsheets, and email threads. In the v0.1 platform, every page of every uploaded file went through Claude for summarisation before it was chunked and embedded, regardless of the file and contents. This was slow, expensive and dropped key information like precise numbers and dimensions engineers need.

We rebuilt the pipeline around a simple rule: look at the file and what's on a page before deciding how to read it. Text and tables are read directly, no AI model involved. Drawing and sketch pages, the ones with no usable text, are passed to Claude APIs, using Sonnet for a single pass that reads every label and dimension before describing the image. On our first test batch, processing time dropped from 93 seconds to 25 seconds, with accurate understanding of critical design and contextual information.

Diagram of Bite's v1.0 ingestion: each page is inspected and routed either to a direct read for text and tables with no model involved, or to Claude Sonnet for drawings and sketches, which reads every label and dimension before describing the image. Processing time per batch fell from 93 seconds to 25 seconds.

Diagram of structured extraction in Bite: files with a predictable layout are read directly, files without one go to Claude with a strict schema, and both produce a fixed structural element record with type, reference, section, grade and source page, which search then queries.

The same principle applied to how we pulled structural details out of a document, e.g. a column's size, a beam's grade. Where a file has a predictable structure, e.g. an ETABS table export, a Tedds calculation export, we read it directly, no AI involved. Claude is reserved for the cases a direct read can't handle: scanned drawings, calculation PDFs, anything without a fixed layout. Its answers come back in a strict, predefined format rather than free text, so the rest of the system can trust what it gets. Search itself runs on a separate model built specifically for that job, using OpenAI's text embedding models, so each part of the pipeline uses the model suited to the task.

We also built an evaluation suite from real engineering files to help us benchmark models and the broader reliability of the system, so we could continuously improve the way the product interpreted the engineering files. This suite helped us catch bugs early while developing at pace. We added extensive analytics (PostHog) and LLM observability (Phoenix, self-hosted) to ensure we could proactively measure and improve the product, based on real usage and behaviour.

Diagram of Bite's evaluation suite and observability: entity extraction precision and recall, numeric tolerance on dimensions, chunk quality and fact coverage, and baseline regression bands, alongside PostHog product analytics and self-hosted Phoenix LLM tracing.

Let's talk →