I build practical AI tools, test where they help and where they fail, and help people get comfortable using them. My focus is AI Enablement, Adoption, and Implementation: finding useful problems, designing workflows around real work, checking the results, and keeping people in control.

I come from enterprise IT support and workflow systems, and I have a BS in Information Technology with an AI concentration. I care less about a flashy first demo than what happens when someone has to rely on the tool on an ordinary Tuesday.

Portfolio & case studies · AI in practice · Writing · Building in public on X

At work, I configured two Microsoft 365 Copilot agents around tasks support employees already do:

• Response templates: an agent uses existing SharePoint documents to suggest a relevant template or a draft response. The employee reviews and edits the result before sending anything.
• Ticket categories: an agent uses an Excel category list in SharePoint to suggest a ServiceNow category. The employee makes the final selection in ServiceNow.

The interesting work wasn't just getting an answer out of a model. It was making the workflow useful and understandable:

• Retesting difficult customer emails after changing instructions, especially mixed-issue requests and cases where the answer could invent details.
• Showing coworkers how to use the agents, walking through examples, and explaining when to check knowledge articles and procedures.
• Directing, reviewing, and editing two AI-assisted instructional guides that were distributed to employees after manager approval.
• Updating the agents' source material when response templates changed.

Some coworkers reported saving time and continued using the agents. That's qualitative feedback, not a measured accuracy rate, adoption percentage, or productivity gain. The agents make suggestions; they don't automatically update tickets or send messages.

Read the anonymized workplace case notes →

A fictional help desk with a ticket queue, history, AI summaries, category suggestions, and editable reply drafts. The technician reviews suggestions and controls what gets saved.

I used a small 12-ticket evaluation to examine usefulness, factual mistakes, repeated questions, unsupported commitments, response time, and cost. It's evidence about this demo, not a general model accuracy claim.

Shows: workflow design · human review · evaluation · local/cloud model tradeoffs
Source on GitHub

A portable set of commands for AI coding agents across Codex, Cursor, and Antigravity. It asks agents to define scope, challenge their work, show verification evidence, and explain what they did.

The project separates written instructions, scripted checks, and observed live sessions instead of treating them as the same proof.

Shows: guardrails · scope control · verification · multi-tool consistency
Source on GitHub

A local assistant experiment that separates current facts, previous values, recent conversation, and historical memory. It explores what happens when old information competes with something a person explicitly corrected.

Shows: memory reliability · provenance · retrieval boundaries · failure recovery
Source on GitHub

A game companion that retrieves information through Blizzard's API instead of assuming the model remembers the right facts. Local and cloud models use the same tool-calling workflow, with tests for routing and failure handling.

Shows: tool calling · API integration · grounded answers · error handling
Source on GitHub

I start with the work, not the model.

1. Find a useful problem. What is taking time, causing confusion, or getting done inconsistently?
2. Use the right context. Ground the workflow in the documents, procedures, or structured data people already depend on.
3. Test the ugly cases. Ambiguous requests, missing facts, stale information, and confident answers that shouldn't be confident.
4. Keep the human in the loop. Make suggestions inspectable, editable, and easy to reject.
5. Teach the check. Adoption includes knowing when the tool is wrong or when to consult the source.
6. Measure what changed. Where possible, compare outcomes and correction effort instead of calling a good-looking demo a success.

I'm still learning and testing these habits in public. The failures are often the most useful part.

• Enterprise IT: Tier 3 end-user support since 2020, with ServiceNow incidents, problems, knowledge, troubleshooting, and peer guidance. This is the foundation I bring into AI work, not the main pitch of this profile.
• Workplace AI: Microsoft 365 Copilot · Copilot agents · SharePoint · Excel · ServiceNow
• AI prototypes: Python · FastAPI · Ollama · xAI API · structured outputs · retrieval and memory
• Web and project tools: JavaScript · TypeScript · React · HTML/CSS · Three.js · SQLite · Git · GitHub

• “Could AI Do This?” Is the Wrong First Question — starting with the actual problem, not the available AI.
• Beyond Coding: Cursor for Research, Notes, and Writing — connected knowledge work and reviewing AI edits.
• I Changed My Mind. Did My AI? — what it takes for an AI system to handle a corrected fact.

I still love software that has personality. The weird stuff stays on the workbench.

• Commit City — GitHub contribution history turned into a 3D city.
• Mutation Microscope — exploring genomic variant-effect predictions and what the visualized data actually supports.
• Gravity Well, Dial-Up Fun, and Y2K Oracle — because software is allowed to be strange.

Build useful things. Build weird things. Help people use them.

cyb3rcricket.com · Contact me · @Cyb3rCricket on X