Redait Tsegaye Legesse

← Projects

Overview

Across this portfolio, every project is really a chain of computational-BIM steps. IFC comes in, geometry is rebuilt into native elements, parameters are mapped, schedules and a bill of quantities fall out, disciplines are clash-checked, documents are issued. Today I drive those chains by hand across Revit, Rhino.Inside.Revit, Grasshopper and Solibri. This section explores a single idea: that the same chains can be described once, as tools an AI agent calls in sequence, so the agent runs the workflow end to end while I review at the decision points.

How it works, in plain terms

You do not need to know the internals, and neither do I claim to have written them. The idea is simple: you type what you want in plain language, Claude works out which commands to run, the MCP server passes those commands to Revit, and the result comes straight back to you.

Prompt in, model changes and answers back out. Everything in between is the open-source server doing the talking to Revit.

What one command looks like

An illustrative example of a single instruction becoming actions on the model, using tools that exist in the server today:

Illustrative. tag_all_rooms and create_schedule are real tools in the base server; this shows how the interaction reads, not a captured session.

A working proof of concept

The idea is only credible if a piece of it runs. The cleanest starting point comes from the SNAM project, where decades of gas-network coordinates had to become a Revit model, and where the real difficulty was that field data carried human recording errors. So the first tool is a QA gate that validates a coordinate dataset before any model is built, flagging bad records rather than silently constructing a wrong pipeline. Because this is pure geometry math it needs no Revit connection and runs today in plain Node. Given a deliberately corrupted sample, it reports:

  16 rows checked · 15 well-formed points · 4 error(s), 2 warning(s).

  ✗ [off_route_elbow]  Row 8  (P007): elbow lies 1.80 m off the incoming pipe axis, the recorded position doesn't match the route.
  ✗ [missing_elbow]   Row 11 (P010): the route turns 90° here but the point is recorded as a pipe (BARR), not an elbow, a forgotten elbow reading.
  ✗ [missing_coord]   Row 14 (P013): missing/invalid coordinate(s): z.
  ✗ [duplicate_id]    Row 15: duplicate id "P010" (first seen row 11).
  ! [outlier_jump]    Row 16 (P015): coordinate jumps 4930 m from the previous point (493× typical spacing), likely a mis-recorded coordinate.
  ! [spurious_elbow]  Row 15 (P010): recorded as an elbow but the route is effectively straight.

  BLOCKED, resolve the errors above before building the model.

The off_route_elbow and missing_elbow cases reproduce the exact failures the SNAM case study describes. The point is not the tool in isolation. It is that an agent can now run this check, explain each anomaly in plain language, and ask how to resolve it, as the first reviewed step of an automated "coordinates in, coordinated model out" workflow.

Proposed tools

Around twenty-seven tools, grouped into families, each anchored to a workflow already shown in this portfolio and each following the base project's existing pattern. Complexity is rated LOW (reuses existing logic), MED (real API work), HIGH (needs an in-process bridge or external service).

How it maps to my projects

The pattern across all eight projects is the same: the copilot never invents the method. Every enhancement wraps a technique I already built and shipped, and makes it callable, sequenced and reviewable by an agent.

Roadmap

Honest scope

This is a research direction, and it is stronger for naming its limits. A few worth stating plainly:

• Copilot, not autopilot. The agent plans and drafts; I review at the decision points. Write operations default to a dry run, and experiments happen on model copies, never production files.
• The pipeline is in-process. Rhino, Grasshopper and Dynamo are reachable precisely because they run inside Revit; workflows that need them outside Revit are out of scope for this architecture.
• Heavy simulation runs offline. Full daylight and energy solves are too slow for an interactive tool, so the design uses a trained surrogate for exploration and reserves full simulation to confirm finalists, the same approach as the Tour Guillot thesis.
• Data governance matters. Confidential models cannot be sent to a cloud model; a serious deployment would use a local or on-premise model. Confidential project detail is withheld here regardless.

The defensible version, in one line: an AI agent that orchestrates the computational-BIM tools I have already built, in-process, with me at the review gate. Everything in the "build today" and "prototype" lanes is reachable now; the rest is labelled honestly as research and vision.