Context is grounded in the current environment’s actual configuration. It records resource relationships, operating conditions, and decision background, and evolves with deployment changes. I use a few maintenance rules.

Environment documents are organized by responsibility.

The documents also preserve context absent from configuration files, such as reasons for customizations, areas maintained manually, and recovery conditions.

I generally use Kustomize for services I deploy myself, retaining flexibility over configuration. Directories group services by responsibility. Single-component services remain flat, while multi-component services split where needed.

Clear entry points and hierarchy help the agent locate the change scope, inspect rendered manifests, and extend the existing structure with less duplication and scattered configuration.

For potentially risky operations, my principle is to use mature tools with explicit rules and auditable execution. I keep direct environmental access behind those tools, which constrain entry points and scope and retain execution records. The agent invokes them within granted authorization.

Repository access lets an agent read configuration, prepare patches, and draft plans. Actual maintenance also requires visibility into runtime state and authorized access to nodes.

I manage physical-node and VM SSH connections centrally through XPipe and expose remote operations to the agent through MCP. Connections initially used to inspect configuration and build context also support later authorized maintenance. The agent can check settings, execute commands, and collect results through those tools.

With tools connected, the workflow becomes reading documentation and current state, listing the plan and impact, confirming it, executing in stages, and collecting acceptance evidence. When assumptions fail, the plan needs revision before continuing.

My earlier environment documentation was sparse, mostly because I had put it off. It was my own Homelab, and its complexity was manageable. I knew the purpose of subnets and VLANs, routing and access boundaries, service locations, entry points, and storage dependencies well enough to keep much of it in my head.

Once AI became involved, I granted the necessary configuration-reading access through tools. For routers and switches, I exported configuration backups and asked the agent to organize networks, routes, and access rules. It combined those with the declarative repository to document service access, deployments, and storage dependencies. I checked the results and supplied background.

Using AI to prepare environment documentation was much easier than I expected. Router and switch backups were particularly effective. The agent could connect facts spread across interfaces, VLANs, routes, and access rules. Workload, Service, ingress, and storage manifests similarly revealed access paths and dependencies. Documentation finally stopped feeling like a task that required saving up energy for a dedicated session.

I added explanations absent from the configuration, including the reasons for network divisions, access boundaries, and customizations. Combining configuration facts with human context allowed the documentation to explain both operation and intent. Credentials stay outside the general context.

The cluster had gone nearly two years without systematic upgrade maintenance. Kubernetes evolves quickly, while a kubeadm environment still requires research into version changes, supporting-component adjustments, node upgrades, and verification. I decided to try delegating this upgrade to AI.

The work progressed from 1.32 to 1.36 one minor version at a time and included replacing the node operating systems.

I first asked the agent to read environment documents, maintenance scripts, and cluster state and prepare a plan. The aim was to connect research, compatibility assessment, risk identification, and execution. I reviewed the plan and made key decisions.

My Homelab can tolerate brief interruptions during maintenance, so some choices reflected the cost of maintaining a personal environment. I remained involved in outage decisions and exception handling.

The biggest change was being able to step away from the terminal. The agent could turn research into operations, then inspect results and troubleshoot. I mainly reviewed plans and confirmed key stages. According to my notes, the main upgrade work took about a day, excluding preparation of the documentation.

I started the second case with Grafana. The old version’s dashboards were mostly edited in the UI and stored in the database, outside the project’s context. I opened them when needed and added panels, but rarely documented why metrics were chosen, how dashboards should be organized, or what remained to improve.

After upgrading, I tried bringing existing dashboards into declarative management with Git Sync.

I asked AI to reassess the dashboards against the actual environment, distinguishing upstream content from local adaptations and identifying the needs of networks, hosts, storage, and services. It located configuration, compared content, and prepared changes. I supplied usage habits and design intentions, then we decided which information to retain and which monitoring gaps to address.

The scope expanded to metric collection and alert rules. I also involved AI in organizing, writing, and maintaining rules across the Homelab. Examples include checking collection coverage against device and service responsibilities, organizing host, storage, certificate, and availability rules, and making alert severity and notification wording consistent.

With dashboards in Git Sync and collection and alerting in declarative manifests, the agent can follow relationships from targets to metrics, panels, and alerts. I mainly confirm whether an alert deserves attention, whether its conditions match actual use, and whether deployment produces the intended result.

Being able to organize the observability design as a whole mattered more than bulk JSON edits. Configuration relationships, design notes, and improvements I had lacked time to address now have a maintained home. New services and network changes can draw on that context to extend monitoring and alerts together.

I traditionally kept deployment and maintenance scripts in scripts/. OS initialization, network setup, disk expansion, runtime installation, and monitoring integration gradually accumulated reusable procedures.

Managing scripts as part of the project brings several benefits.

AI helps compare, extract, and update scripts. I review critical changes before authorized execution. Each task leaves scripts and explanations that become usable context for the next.