AI Integration & Agent Systems Projects

Goals: Put AI to work inside a business on the business's own information, without handing that information to a third party and without the system inventing answers.

Challenges: Most businesses do not have an AI problem, they have a retrieval problem. The knowledge sits in documents, tickets, spreadsheets and people's heads, and a general model knows none of it. The three obstacles that actually decide these projects are whether the data is allowed to leave the premises, whether an answer can be traced back to a source, and what the system is permitted to do once it is confident.

Solutions: Ground the model in the company's own material through retrieval rather than fine-tuning, which keeps it current and auditable. Run inference locally on open-weight models when the data cannot leave, and use a hosted model when it can. Separate reading from acting: the system is free to investigate and summarize, and anything that changes state goes through an approval gate. Give every automated action an audit record from the start, not after someone asks for one.

Outcome: This is the architecture I build to, and the reasoning behind it is what I bring to an integration: start with the retrieval and the permissions, not the model. It is the basis of the AI integration work I take on.

Goals: Build an operations assistant that investigates real infrastructure problems across many hosts, rather than answering questions about infrastructure in the abstract.

Challenges: When an engineer is three hours into an outage the bottleneck is rarely typing. It is reading: logs across six hosts, a configuration that changed last Tuesday, a metric nobody was watching. An assistant that cannot reach the hosts cannot help with any of that, and one that can reach them is now a system with real power on real servers.

Solutions: An orchestrator accepts a job, decides which agents to run, and tracks the job through its lifecycle. Agents reach hosts over SSH and are targeted by tag rather than by hostname, so a job can address a role instead of a list. Results come back as structured job output that can be inspected afterward, and a local model through Ollama does the reading and the correlation. Deterministic code handles anything a model is the wrong tool for.

Outcome: A working platform that does the investigation legwork and hands an engineer a grounded answer, leaving the decision with the engineer. Not deployed in customer production.

Goals: Decide what an automated system is allowed to do on its own, which turned out to be the hardest problem in the whole build.

Challenges: An agent with shell access on production is useful exactly in proportion to how dangerous it is. Granting it nothing makes it a chatbot. Granting it everything makes it an outage waiting for a confident wrong answer.

Solutions: No write access unless it is explicitly granted. An approval gate before anything changes state. Refusal when a request falls outside the system's defined scope, rather than a best guess. Deterministic fallbacks for the cases where a model should not be in the loop at all. An audit record of every action taken, including the ones that were refused.

Outcome: A safety model that is effectively an acceptable use policy expressed in code. The same five questions apply to any organization introducing AI tooling, which is why this is the part of the work I am asked about most.

Goals: Make a body of private technical documentation answerable in natural language, at a scale a single business actually has rather than a scale a research paper assumes.

Challenges: Retrieval quality is decided by chunking long before it is decided by the model. Split a runbook at the wrong boundary and the retrieved passage is missing the step that mattered. Embeddings also have to persist across restarts, or every session pays the indexing cost again.

Solutions: Document chunking tuned to the structure of the source rather than a fixed token count, embeddings generated locally with nomic-embed-text, semantic retrieval over a persistent ChromaDB store, and generation by a local open-weight model so no document leaves the machine. The retrieved passages stay visible alongside the answer, so a reader can check the source instead of trusting the summary.

Outcome: A retrieval pipeline small enough to run on one machine and honest enough to show its working. This is the pattern most small and mid-sized businesses need, and it is far cheaper than the alternatives they get quoted.

Goals: Bring AI-assisted investigation into day-to-day operational troubleshooting on a real-time communications platform, and find out where it genuinely helped.

Challenges: Introducing a new tool into an on-call workflow is mostly a trust problem. Engineers under pressure will not use something that is right most of the time unless they can tell which time they are in.

Solutions: Applied LLM tooling to log reading, correlation across hosts, and documentation of what had happened, then measured where it helped and where it did not instead of assuming it would. Kept it to investigation rather than remediation.

Outcome: It earned its place in investigation and documentation, and it did not earn a place in decision making. Knowing which half is which is the useful result.