Atlas

AI engineering for enterprise expertise. Three agents, a senior team, decades of domain knowledge made operational.

Atlas architecture diagram

Context

The most valuable thing in an enterprise environment isn't usually visible from the outside. It's the institutional knowledge — the accumulated judgment that took the team decades to build. How proposals actually win in this sector. Which legal language has been negotiated a hundred times before, and which is the dangerous boilerplate. What metadata structure makes the difference between a document that gets found and one that gets lost. None of this is written down. Most of it is in people's heads.

Atlas is enterprise AI work for a renewable-energy US Development team. The workflows sit across Development, Legal, Construction, Engineering, Interconnection, Procurement, Finance, and Document Control — the parts of the business where utility-scale solar, wind, and battery-storage projects actually move. The people I work with have spent more than twice my lifetime in this sector. They know things I haven't earned the right to know yet: where the real friction lives, which details matter, and which only look like they do. That knowledge is the company's most expensive asset and almost none of it is structured.

Atlas is what I built to operationalize it.

The bet is that AI's real role in enterprise isn't replacing expertise — it's scaling expertise. A senior team's judgment, encoded in agents, applied a hundred times faster than the team alone could apply it. The technology has to be invisible in service of the knowledge. That's the whole game.

I built the AI layer. The team brought the expertise. The agents are how the expertise scales.

What shipped

Three agents in the system. Each one solves a real workflow bottleneck, and each one is a different shape of how AI carries human expertise.

The task-proposal agent. It pulls every task proposal received for a specific project from the database, normalizes them into comparable structure, scores them against criteria the team has refined, and produces the structured rundown a senior reviewer would want before deciding where to focus — strengths, weaknesses, fit-for-context, risks, entity extraction, relationship context, and a recommendation for which proposal looks strongest. Critically, it explains its reasoning at every step, so the senior user can verify the agent applied the right judgment rather than just trusting the output. The user makes the final call. The agent does the reading, categorization, and synthesis that previously took hours of senior review time — and gives the reviewer their judgment back, applied at speed.

The legal drafting agent. It takes legal documents and drafts them iteratively in collaboration with the user. The user defines the scope, the agent drafts a section, the user marks parts to lock, iterate on, or rewrite. Each draft iteration carries forward the user's previous decisions — what they kept, what they rejected, what they refined. By iteration three or four, the draft has converged on the user's intent in a way pure auto-generation never could. Most legal AI tools generate a full document and ask the user to edit it. This agent matches the actual practitioner workflow — draft, refine, draft, refine — accelerating the slow first-pass drafting that bottlenecks before serious review can begin.

The metadata agent. It restructures metadata in the company's document management system, and uses a combination of Python and AI for the analysis layers. Less visible to end users than the first two, but load-bearing — clean metadata is what makes the document layer searchable, governed, and integrable with anything built on top of it. Fix this and dozens of downstream workflows get faster.

This agent is a hybrid by design. The structural cleanup is deterministic Python — rules the team has refined over years of fighting with metadata drift. The market research and analysis components are AI, because those are the parts where pattern recognition and synthesis across documents matter more than rule-following. Knowing where to draw the line between deterministic and AI is itself a senior-engineering decision. AI for the parts that benefit from intelligence; code for the parts that benefit from reliability.

Three different problem shapes — decision support, generative drafting, structural cleanup — sharing one architectural pattern. Each agent is built around the workflow people already do, augmenting it rather than replacing it. The user stays in the loop. The agent does the work that's slow, repetitive, or pattern-recognizable, and the human does the work that requires judgment.

The ecosystem that makes this work is what I built. The expertise that makes the agents worth running is what the team brings.

What landed

The work cleared the bar that matters most in enterprise AI: it got from prototype to executive approval for rollout. That's the milestone. Most enterprise AI projects don't reach it.

What I'll say publicly stops there. Specifics about adoption, deployment timing, and the workflows the agents enter stay inside the company. What matters isn't the metrics — it's the architecture and the partnership that produced something the senior people in the room said yes to.

The people whose judgment the agents encode looked at the work and decided to scale it — the only approval that matters.

What I learned

Doing AI work inside an enterprise is genuinely a different problem than doing AI work on personal infrastructure. The hardest parts aren't the AI parts. They're the parts where the AI has to integrate with systems that already exist, used by people who didn't ask for AI, in workflows that were designed for humans. The technology has to meet people where they already are. Most enterprise AI projects fail because they don't.

The second lesson is that the partnership matters more than the architecture. I could have built three technically excellent agents that nobody used. The reason these landed is that my collaborators knew where the actual bottlenecks were, who used what tools, where institutional friction lived. I provided the AI infrastructure; they provided the targeting. Without their half, my half doesn't matter.

The hardest lesson is the one about credit. The work I'm describing on this page is real and I'm proud of it. But the page can't claim it as solely mine without lying. I built the AI systems; I was not the whole team. Personal pages reward overclaim and the discipline is to not take that reward when the work was joint. The right framing is the partnership framing. The expertise is theirs. The system design is mine. The output is ours.


Next: extending the same approach to more workflows. The shape of the work continues; the specifics aren't mine to publish.