This was not a normal internship where I shipped one small feature and disappeared into the backlog. My work at Peoples First Insurance turned into a full lifecycle infrastructure engagement: build the system, operate it, advise leadership on what it meant, and then shut it down cleanly when the business direction changed.
I started as an AI and software engineering intern and ended up functioning more like an autonomous AI contractor and technical consultant. I reported directly to the company president, worked around real insurance workflows, and had to think about the boring parts that make systems matter: security boundaries, backups, operational ownership, vendor risk, and what happens when a prototype becomes too important to leave half-managed.
I am keeping proprietary data, client details, and internal logic out of this write-up. The useful part to show publicly is the shape of the work.
The Build Phase
The first phase was architecture and deployment. The company had a practical question: could localized AI infrastructure reduce friction in insurance workflows without sending sensitive data through a messy collection of public tools?
That pushed the work toward internal systems instead of generic demos. I built custom tooling around document preparation, Applied Epic context, local data access, and AI-assisted retrieval. The biggest piece was an MCP-style framework that let Claude interact with insurance-specific operational data through controlled tools instead of free-form access.
The important design choice was not "give the model everything." It was the opposite:
- Give the model narrow tools.
- Keep the data boundary local.
- Return compact evidence instead of giant dumps.
- Build around human review where the workflow could affect a real record.
- Make the system useful enough for leadership to test, but constrained enough to avoid turning AI into an uncontrolled admin user.
That phase also included provisioning and maintaining the local server environment that hosted the custom agents, databases, and workflow automation.
The Operations Phase
Once the infrastructure existed, I became responsible for keeping it sane.
The server environment was designed as local intranet infrastructure. Sensitive agency data stayed inside the local company network rather than being exposed as a public service. I handled Linux administration, uptime troubleshooting, environment management, and the automation around nightly backups.
That experience changed how I think about AI systems. A model demo can be impressive in a meeting, but the operational questions show up immediately after:
- Who owns the server?
- Who knows how to restart it safely?
- Where are the backups?
- What happens if the database changes?
- What can the model read?
- What can the model write?
- What should never leave the building?
Those are not side questions. In a real business, those are the product.
The Consulting Phase
The role eventually moved beyond code. I became a filter between technical possibility and business reality.
Part of that meant evaluating external AI and insurance SaaS platforms against the custom internal systems I had built. The question was not whether a vendor looked impressive. The question was whether the company had a clear operating model, budget, staff capacity, and risk tolerance for whichever path it chose.
That led to one of the more important conclusions of the engagement: bespoke internal AI infrastructure can be powerful, but without a dedicated owner or fractional AI architect, it can become an operational liability.
That is not a failure of the build. It is the difference between "this works" and "this organization can responsibly own this long term."
The Spin-Down Phase
When the agency pivoted toward external SaaS tools, I helped execute the clean break.
That meant shutting down the custom environment deliberately instead of just abandoning it. I terminated backup jobs, removed lingering runtime dependencies, wiped local hardware, and extracted the non-proprietary structural pieces that could be made public safely.
That extraction mattered. The public repositories do not contain client data, business-specific logic, private vault material, or internal credentials. What survived was the reusable architecture: MCP wrappers, document tools, desk displays, local retrieval systems, and patterns for building safer AI infrastructure.
The public-safe pieces I pulled out of that work are:
- UwUGreed/PDF-Condensor, the local PDF splitting utility.
- UwUGreed/Doc-Cleaner, the document-prep workflow.
- UwUGreed/desk-gadget, the Pico W renewal display and read-only API.
- UwUGreed/obsidian-mcp-wrapper, the reusable vault retrieval and MCP wrapper architecture.
What I Actually Learned
The strongest lesson was that technical range matters most when it connects to judgment.
I wrote Python, built MCP servers, managed Linux boxes, designed local network boundaries, created backup workflows, evaluated SaaS tools, and helped decommission infrastructure. But the real value was learning when to build, when to harden, when to advise, and when to shut something down.
That is the part I am taking forward. I do not want to just make impressive prototypes. I want to build systems with an honest lifecycle: useful, bounded, maintainable, and disposable when the business no longer needs them.
That is a much better standard than "it worked on my machine."