CircularAI

Every developer adding an AI feature was re-implementing the same communication logic, with inconsistent results. AI communication wasn't going to be a one-off integration for a single feature — it was going to be a core part of the platform.

I designed and built a shared service, internally called Cai, to own the AI API connection, WebSocket communication, response streaming, background execution, error handling, persistence, response adaptation, and delivery to users over SignalR.

Features only had to define the request they needed; everything else came from the shared service. By the end of the project it was the standard way the platform talked to the AI system, used across roughly 25–50 integration points.

Some operations sent files of around 10 MB to the AI system for analysis and took several minutes to come back — too slow for a normal request/response call, and not something you can just leave a thread blocked on.

I built a background-task mechanism instead: the app creates a task record, kicks off the AI operation, and hands the AI system a callback endpoint to hit once it's done. That decoupled the request from the processing time and gave the platform a pattern we reused for other long-running work later.

For the React frontend consuming SignalR events, I designed a provider/context-based subscription pattern: a component subscribes to a named message with an action to run when it arrives, and unsubscribes automatically on unmount.

The frontend developers implemented it from my design and examples. My own React and TypeScript experience was still developing at the time, so I used AI tooling to iterate on the implementation and get the architecture across clearly.

I ended up implementing most of Missions, Projects, and Procurement — including their underlying data model in EF Core — along with authentication and authorization (JWT access/refresh tokens), Elasticsearch search, and parts of the workflow and background-processing systems, plus taking over an existing workflow implementation from another developer.

Working across that much of the platform meant I usually had a sense of how a change in one area would affect another, which is why the harder problems and newer subsystems, like Elasticsearch, tended to land with me.

Where I could, I tried to keep the harder architectural decisions out of the way of the people building on top of them — developers shouldn't need to understand why Cai works the way it does to use it correctly.

I tried to do the same with specs: using structured templates and AI-assisted drafting to turn informal requirements into clearer technical write-ups, so developers spent less time guessing at what was actually needed.