AI applications for teams past the demo.
I'm Gregory O'Connor. I work with teams that already have a workflow, partial data, and pressure to ship. I build the first useful version, make the tradeoffs visible, and stay close enough that evaluation, privacy, cost, and handoff do not become afterthoughts.
Most of the work right now is with Claude and OpenAI, retrieval layers, structured outputs, and evals.
Best fit: founders, operators, and internal teams where bad AI output costs real time, money, or trust.
Where I'm useful
Your team already has the workflow, documents, and judgment. You need the AI system that makes them easier to use.
You want a useful first version for a specific business problem, not a generic chatbot or strategy deck.
You care about answers tied back to source documents, privacy boundaries, failure modes, and what the system will cost to run.
You need someone who can translate between business leads, subject-matter experts, vendors, and engineers.
What I build
Prototype to release-candidate path
A useful first version is more than a demo that works on friendly inputs. I build the product path and the system together: scope, model behavior, retrieval, tests, deployment, and the handoff plan.
Document and knowledge systems
Knowledge systems live or die on boring decisions: what the retrieval layer returns, how sources are cited, and what happens when the model is wrong. I design that layer so quality problems show up before users find them.
Architecture, evals, and what to log
Once a system has more than one model or service, the hard part is rarely the model. It is what calls what, what gets logged, what needs human review, and what becomes an audit problem later.
Working alongside your team
I can build independently or join an existing product or engineering team for the AI-specific work. The useful version is staying close enough to ship, then handing off the prompts, eval set, docs, and cost assumptions cleanly.
Where this applies
The common thread is document-heavy work where teams need source-grounded answers, clear uncertainty, private data handling, and a human review path. The domain changes; the constraints repeat.
- Legal and public-interest workflows: AI-assisted citation finding, authority recommendations, and source-grounded document review that help legal teams deliver clearer guidance while keeping confidential data and human judgment protected.
- Real estate operations: portfolio intelligence, resident service, engineering and maintenance workflows, and diligence tools that connect leases, rent rolls, work orders, inspections, operating reports, communications, and human follow-up.
- Internal knowledge systems: assistants that work against private reports, policies, and institutional memory instead of the open web.
- Build-vs-buy decisions: helping teams decide what should become software, what should stay a process, and where AI actually changes the workflow.
How engagements work
Start with the smallest engagement that can answer the important question.
Strategy + Architecture Sprint
1–2 weeksWe look at the workflow, the data, and the existing systems, then write a build plan with explicit go/no-go gates. Not a vision document.
Prototype Sprint
2–4 weeksA working version in your environment, narrow enough to prove value. Includes evaluation, cost assumptions, and an honest read on whether to harden or stop.
Build + Ship
4–10+ weeksI stay with the build through integration, testing, and handoff. The goal is a system your team can operate without depending on hidden prompt tricks or heroics.
Recent work
Confidential entertainment-industry application — concept to release-candidate path
A recent product started as a specific entertainment-industry idea, not a chatbot wrapper. I helped shape the product, architecture, data layer, AI behavior, privacy boundaries, deployment path, and release plan together.
The build moved from early concept to working prototype, MVP, and credible 1.0 release-candidate path in weeks. The important lesson was not speed by itself. It was that product decisions, implementation, tests, documentation, and infrastructure stayed in the same loop.
- Built around authentication, personalization, a curated knowledge base, structured model outputs, evaluation paths, and privacy boundaries
- Used an AI-native development workflow where product gaps surfaced through working software, not a long planning cycle
- Treated human judgment as part of the system design, not as an afterthought
Distributed AI compute platform — architecture and governance from scratch
A startup was building a platform to coordinate AI training workloads across distributed hardware. The technical concept was promising but the founder needed someone to turn it into a real operating plan. I wrote the whole thing.
- Mapped data flows across five interconnected systems. The key insight was that the heaviest data never touches the central server, so the control layer needed to observe and govern, not relay
- Designed the governance framework: who can participate, how work is verified, how to revoke access without breaking a running job
- Wrote operator field guides, onboarding documentation, and a security progression roadmap from open alpha through sovereign deployment
- Built a phased 90-day pilot plan with explicit go/no-go gates. The founder needed to know when to keep pushing and when to stop before overcommitting
Multilingual narrative monitoring — pipeline design for public communications
Designed a system to track how messaging themes evolve across languages and channels. The client needed signal, not surveillance.
- We kept a human editorial layer because full automation would have produced more false confidence than useful insight
- Focused the system on trend clarity and responsible framing, not "gotcha" classification
- We cut the first version to theme tracking and source comparison. Trying to infer intent across languages this early would have created more noise than signal
I don't do political microtargeting, covert persuasion, or surveillance work. If your use case needs careful boundaries, we figure those out first.
How I usually work
Most projects start with one problem that matters, a pile of imperfect context, and too many theoretical options. I narrow the scope fast, get something testable in front of real users, and make sure quality, latency, cost, and failure modes are visible before the system grows. If the first version looks promising, we harden it. If it doesn't, you find that out in weeks instead of after a long, expensive build.
About
I'm Gregory O'Connor. I build AI systems that have to hold up outside the demo. The work I like sits where product judgment and model behavior stop being separate problems.
MIT-trained Ph.D., based in New York. I've been building technical systems for a long time. Recent work includes a confidential entertainment-industry AI application and advisory work with an AI startup.
I'm usually most useful when a team has a real workflow, partial data, and pressure to ship before the system is fully understood.
Send the workflow
A first email does not need to be polished. The useful version says what the workflow is, who uses it, what data is involved, and what would make the first version worth keeping.