AI tools and integrations
Tools I create and develop at work and in personal projects, from agent integrations to search and document processing.
Internal AI toolkit
I created an internal AI toolkit that configures Claude Code and Codex for different teams. Role-specific packs combine reusable agent skills with relevant company context. The toolkit contains both official vendor MCP's and custom MCP's I built for internal use.
The design separates workflow instructions from code-based checks on tool use. Deterministic hooks block configured write operations, while access to each service still depends on the user's account permissions. The installer backs up the configuration it changes. Connector verification distinguishes a registered tool from a working connection.
I continue to guide the toolkit's technical direction while the AI Platform team develops the shared components and integrations.
Example: service-desk requests
I designed the service-desk workflows around the information an engineer needs before fulfilling a request. Starting with a Jira Service Management (JSM) ticket, the agent identifies the request type and checks the affected employee, requested systems, access level, business reason, and required approvals. It follows linked Jira issues and Confluence procedures, then uses service-ownership and role-based access records to identify the system owner and the approver separately. Those can be different people, and the workflow requires evidence for each.
For onboarding, the workflow checks the start date, manager, team, and employee status using the request and authorized BambooHR information. A request to “give this new hire the same access as a colleague” triggers a closer check: does that colleague have the same role, are they still active, and would copying their access carry over privileged permissions the new hire has not been approved to receive? The workflow flags missing approvals and conflicts between the ticket, people records, and access requirements. Relevant Slack conversations can explain urgency or recent coordination; a message saying “approved” does not replace the required approval record.
I made the output specific enough for the next person to act on: a field-by-field completeness check, a list of requested systems and access levels with the corresponding owners and approvers, and the unresolved questions blocking fulfillment. Missing people data is marked as not checked. Uncertain ownership is escalated with the available source references. The agent prepares that evidence for the service desk; a person reviews the request and carries out approved account or permission changes.
Example: incident response after a deployment
I built separate skills for incident triage, technical investigation, Kubernetes runtime checks, and incident-command support. They organize the work around a defined service and time window, with source references connecting the findings to the next diagnostic step.
Consider a Grafana alert reporting increased application errors shortly after a deployment. The agent starts with the Jira Service Management incident record to establish the affected service, environment, known customer impact, and when the symptoms began. It narrows the investigation to the relevant cluster, namespace, and workload, then reads the linked Confluence runbook. That scope determines which dashboards, logs, and runtime objects to inspect, including evidence from before and after the deployment.
With the relevant connections and permissions available, it compares Argo CD application sync and health status with the actual Kubernetes deployment, replica sets, pods, and events. It checks the associated Bitbucket code, configuration, or Helm-chart changes against the runtime evidence. For example, Argo reporting that an application is synchronized does not establish that its new pods are healthy. If those pods are failing readiness checks, the workflow examines pod events, rollout state, and the relevant configuration changes, then compares them with metrics and logs from the same interval. Slack incident threads add responder observations and coordination history to that timeline.
I designed the investigation to distinguish a plausible explanation from an established cause. A configuration regression, a failing dependency, and resource pressure require different evidence, even when each could produce errors after a deployment. The agent marks hypotheses as supported, contradicted, or untested and names the next read-only check needed to distinguish them. If the errors began before the rollout, that weakens the deployment explanation. If metrics are unavailable, resource pressure remains untested. The output includes the source, observed fact, confidence, and missing evidence for each finding; it leaves the cause undetermined when the evidence is insufficient.
The incident-command skill turns those findings into a draft update and handoff: current impact, a verified timeline, active actions and their recorded owners, blocked decisions, and the next update time. It flags actions without owners and separates open questions from confirmed findings. A responding engineer can see what has been checked and what still needs investigation, while the incident commander has a concise account for coordination. Rollback, restart, and other production changes remain decisions for the human responders, supported by the investigation and the applicable runbook or change review.
Server product integration
I built the first version of an integration that connects AI agents to a server product through the Model Context Protocol (MCP). A dedicated team now develops that work further.
Webmind: search for agents
I built Webmind to give my AI agents a shared way to search the web and read source pages. It combines SearXNG search, Crawl4AI page extraction, and a FastAPI service with separate search, extraction, and combined research operations. The research operation extracts source pages concurrently and returns failures alongside the usable results. Its broader search pipeline can expand a query and combine engine rankings, while current-information queries receive different treatment from background reading, including lowering the priority of encyclopedia pages for breaking news.
When a query names a product, pages that repeat generic search terms can still outrank the source for that product. Webmind gives matches to those named entities more weight. Repository searches get a targeted follow-up. If the first results mention a file without locating it, a file-specific query can trigger another search. I compare the raw results with the final ranking to tell whether useful sources are missing or ranked poorly.
I also redesigned how my Hermes assistant coordinates its web searches. Launching several providers in parallel had still left the combined tool waiting for the slowest provider. The revised workflow starts with a smaller search stage using Webmind and a complementary provider, checks the available coverage, and escalates when more research is needed. Deadlines, partial-result reporting, and query caching bound the work. Those coverage checks are heuristics; the answering agent still needs to inspect whether the sources address the question.
Direct requests from agents share a monthly allowance for paid search. I made that search selective and added usage counters with request limits. Article extraction has its own deadlines and response-length limits, with a shared cache that respects the length each caller requests. Failed extracts remain visible beside the source links, so an agent can use the available material and see what it could not read. I continue to test those boundaries as the service changes.
HOA: documents and community information
My HOA is an active community with a constant flow of notices, documents, event announcements, and news. I developed an information system for myself, family, and fellow homeowners, including friends, to make that information accessible. We most often use it for board-meeting information and weekend events. It also helps us find rules, documents, vendor information, and other community news.
The source material arrives in different forms: a notice in an email body, a meeting packet attached as a PDF, an image flyer, or a link to a document elsewhere. The system brings those sources into a searchable corpus while retaining their relationship to the original message and document. Handling that variety is necessary to make information available regardless of how it was distributed.
The system polls Gmail incrementally and separates ingestion from the slower extraction jobs. MarkItDown handles supported Word and spreadsheet attachments. PDF processing first attempts native text extraction with pypdf, then uses pdf2image and Tesseract where a page needs OCR. Linked image flyers have a vision-model transcription path with bounded provider fallbacks. This lets the system choose an extraction method appropriate to the source instead of relying on one parser to handle every document.
Long documents also need to survive the limits of a background job. The PDF worker stores partial text and the last completed page, then resumes in a later run when it reaches its time budget. A page waiting for OCR must remain pending when the budget expires. Advancing the cursor past it would silently remove that page from the searchable record. Processing state and durable failure records make these cases visible and retryable.
After text extraction, an LLM produces structured facts with categories, summaries, additional fields, and evidence references. MiniMax is the configured primary extraction route, with a bounded fallback for extraction failures. Facts are persisted separately from a subsequent people-extraction pass, so a failure in that later work does not discard facts already obtained. The original text remains available alongside the derived information.
Retrieval uses several representations for different purposes. SQLite FTS5 provides keyword search over email and attachment text. Extracted fact summaries are available through mem0 and a FAISS vector index. A separate document index stores embedded passages in SQLite, using bge-m3 through Ollama. The search tool combines keyword and passage rankings with reciprocal-rank fusion. This gives the agent both exact matches and passages relevant to a differently worded question.
For answering, the system assembles relevant facts and document passages with source references, document metadata, and warnings about missing evidence. Page boundaries are retained where the extraction provides them, and a quote tool can retrieve stored wording for closer inspection. The workflow distinguishes facts supported by the retrieved material from details that still need another source. For example, an election notice might establish how many positions are open without establishing their term length; a document for a similarly named board is not sufficient evidence for the missing detail.
Memory and retrieval
An agent was retrieving too much stored context for a question. Tests showed that most of the excess came from retrieving too many distinct memories. Removing duplicate entries would have made little difference.
I chose a lower retrieval limit based on those results, without deleting stored memories. We checked that the answers in a small test set remained available and kept a way to reverse the change.
Switchyard: research delegates and review
I designed Switchyard to assign development and research tasks to eligible AI models. Other model families review changes, with findings and test results kept in the work record. Defined fallback paths handle unavailable providers.
For deeper research, providers receive the same core question with different research angles, such as primary documentation, recent developments, implementation experience, or broader alternatives. Switchyard selects eligible routes and prepares their commands; the coordinating agent executes the research and compares the reports and sources. Webmind is one available retrieval route, while other providers use their own search facilities.
Research completion needs a separate check from process completion. An exited worker or a model saying it is finished does not establish that it produced a usable report. The workflow uses output checks and completion status, while the coordinating agent inspects the reports, follows source references, and resolves specific gaps. Unavailable or incomplete research remains visible. Agreement between models does not by itself establish independent confirmation.
I used research delegates when investigating this search system itself. They gathered outside recommendations, while an audit of the running workflow identified its wait-for-all bottleneck. That gave me two kinds of evidence to compare: what might improve the design, and what the existing system was actually doing.