I Co-Led an Initiative to Scale Engineering Capacity with AI, Reaching ~20 Engineers.

2. 🎯 Project Overview

Question	Overview
What problem did I address? §3 Before state	Interrupted agent work: Token limits stopped active tasks and switching harnesses meant rebuilding context. Human attention bottleneck: Engineers had to find and hand-copy information across internal systems while supervising agents for data security. Unknown cross-repository dependencies: Changes to APIs or schemas could affect consumers across more than a thousand repositories.
What business value did it create? §4.1 Business outcomes	Work continuity and parallelism: Agents can reuse context across harnesses and access tools while engineers focus elsewhere, within security controls. Shared engineering capabilities: Centrally distributed skills and a single MCP endpoint reduce repetitive setup. Safer cross-repository changes: Company-wide search helps identify downstream consumers before changes are made. These are capabilities, not a measured organization-wide hours-saved claim.
What deliverables did I contribute? §4.2 Deliverable and ownership matrix	Agent skills, session handoff, and safety controls: I created company-knowledge skills and cross-harness session handoff, and contributed security guidance and deterministic hooks. Custom FastMCP integrations: I implemented Bitbucket code-search and Freshservice MCP servers to connect agents to company systems. Skills MCP server: I built central skill serving and discovery to replace fragile local copies and symlinks. Docker packaging and distribution: I packaged the FastMCP services in Docker containers and published them to AWS Elastic Container Registry. MCP proxy code review: I served as the main technical reviewer of the proxy implementation.
How did the initiative evolve and get built? §5 Methodology §6 Implementation	Incremental development: I began with capabilities that made my own agent-assisted engineering work easier, introduced useful methods to colleagues, and proposed the work for the roadmap. Distribution and access: The tooling evolved from local skills and containers to central skills, remotely hosted MCP services, and one proxy connection; different components had different owners.
What made implementing Shared Agent Infrastructure difficult? §6 Implementation challenges	Keeping skills synchronized across harnesses: Early distribution relied on local symlinks and manual repository updates. Skills became outdated or needed separate configuration in different agent harnesses. Giving agents access to company systems: Skills could describe where information lived but could not retrieve it. I had to build custom MCP integrations for systems such as Bitbucket and Freshservice, while incorporating safeguards against exposing sensitive data. Making the tooling practical beyond early adopters: Initial local Docker distribution required each engineer to install containers, manage API keys, and troubleshoot authentication. This created additional rollout work before engineers could access the services with less setup.
What capabilities does this demonstrate? §6 Technical implementation §7 Future-project capabilities	Harness and workflow engineering: Configuring agent harnesses, designing skill and tool triggers, and maintaining workflow state across sessions. Reusable integrations: Building custom FastMCP servers, packaging tools in Docker, and collaborating on a remote service rollout. Engineering collaboration: Making agent technology usable through documentation, onboarding, teaching, and feedback from engineers.

My manager summarised my contribution as follows:

„Leistete einen maßgeblichen Beitrag zur Konzeption und Entwicklung eines unternehmensweit eingesetzten Multi-Agenten-Toolings auf Basis individuell entwickelter FastMCP-Server und trug damit wesentlich zur Steigerung der Effizienz im Engineering-Bereich bei."

In English: I made a major contribution to designing and developing company-wide multi-agent tooling based on custom FastMCP servers, thereby contributing substantially to increased engineering efficiency.

3. 🧩 What Made Day-to-Day Software Engineering Difficult: Before State

Chapter summary: Agent usage limits interrupted ongoing work; engineers had to manually shuttle context between tools while supervising agents for security; and unknown consumers across more than a thousand repositories made apparently local changes risky. The table below explains what each problem meant, why it was difficult, and its effect on engineering work.

These problems were not hypothetical. I encountered and solved many of them while continuously improving my own agentic workflow. I then heard colleagues across the company complain about the same limitations and observed how those limitations affected their work. This showed that solutions I had developed personally had not yet become company-wide capabilities, while the unresolved problems continued to limit engineering productivity.

Daily struggle	Why it was difficult	Effect on engineering productivity
Engineers ran out of agent tokens. This was the complaint I heard most frequently. Once an engineer reached a usage limit, the agent could no longer continue the project.	The remaining options were to code manually, switch to unrelated work, or obtain another agent harness. Access to another tool such as ChatGPT required navigating a complicated learning-and-development budget request and payment administration. After access was obtained, the new harness still lacked the conversation and project context from the original one.	Work stopped when the limit was reached, or the engineer spent time obtaining another subscription and reconstructing the context before work could continue.
Engineers had to babysit agents across company systems. They remained at the computer while moving between browser tabs, local files, systems, and applications; finding information; copying it into the agent; explaining it; reviewing responses; and supplying the next piece of context.	Agents did not have the company knowledge or system access required to complete the intermediate steps themselves. Engineers also could not safely leave them unsupervised because an agent might expose PII, credentials, or other sensitive data, or perform a harmful action.	Human attention limited throughput. Engineers could generally progress only one such task at a time instead of letting agents work while they focused on another task.
Engineers could not reliably assess cross-repository impact. A change to an API endpoint, database column, or schema could affect consumers the engineer did not know existed.	The company had more than one thousand repositories across different teams, including many legacy systems. Cloning and searching them all locally was impractical, while Bitbucket's manual code search was difficult to use for tracing longer dependency chains.	An apparently local change could break another service or workflow when an unknown consumer was missed. The prevented bugs cannot be counted from incidents because successful analysis stops those incidents from occurring.

4. ✅ What the Initiative Has Delivered: After State

Chapter summary: The initiative produced reusable agent workflows, safety controls, custom MCP integrations, central skill distribution, and easier access to remote tools. The outcomes and deliverables below distinguish capabilities from measured productivity, and explicitly separate my implementation and review work from teammates’ contributions.

4.1 Business Outcomes

Token limits stopped interrupting engineering work: Engineers can make their token allowance last longer by routing simpler work to cheaper agents. When they still reach a limit, they can continue the existing session in another harness instead of stopping or rebuilding the context from scratch.
Engineers can complete work in parallel: Agents can use company knowledge, access the relevant systems, and operate within security guardrails for longer without supervision. Engineers can therefore focus on another task while an agent investigates or acts.
Shared improvements reach engineers consistently: Centrally distributed skills allow a solution created by one contributor to benefit other engineers without each user maintaining separate local copies for every harness.
Engineers configure one connection for the shared MCP toolset: The MCP proxy routes the underlying servers through one endpoint, reducing the setup and troubleshooting required to adopt new tools.
The company gained agent capabilities before vendor alternatives existed: The custom Bitbucket and Freshservice MCP tools were already in use roughly half a year before comparable official vendor tools became publicly available.
Cross-repository changes are safer and easier to analyse: Agents can search across the company's repositories, identify consumers and dependency chains, and surface affected systems before a change is made. This reduces the risk of breaking unknown consumers.

4.2 Software Deliverables

Deliverable	Components or examples	What it provides	Engineering outcome	Ownership
Skills and initial local distribution	Markdown skills, a setup script, and symlinks into the local agent harness	Reusable workflows and knowledge installed into an engineer's agent setup	Makes tokens last longer, preserves work across harnesses, and directs agents to the right company context	I created several skills; colleagues contributed others, including the subagent-routing skill
Deterministic safety hooks	Controls for sensitive reads, data exposure, and harmful actions	Enforcement when prompt guidance alone is insufficient	Makes longer autonomous runs safe enough to use without constant supervision	I contributed the safety system through prompts, skills, agent context, and deterministic hooks
Custom FastMCP tools	Bitbucket code search and Freshservice; further tools will be added from my account	Direct agent access to company systems, including search across all company repositories	Makes cross-repository dependency and impact analysis practical and removes manual lookup and copy-and-paste steps	I implemented the custom FastMCP servers
Local MCP container distribution	Docker containers published to AWS Elastic Container Registry	An initial installation route for power users who could run the services locally and provide their own API keys	Enabled early usage and validation before a centrally managed deployment existed	I built the local containers and published them to the container registry
Skills MCP server	Central serving and discovery of shared skills	One distribution mechanism across users and agent harnesses	Prevents useful contributions from remaining trapped in brittle, outdated local installations	I built the Skills MCP server
Remote MCP deployment	MCP services deployed to Kubernetes with centrally managed, narrowly scoped credentials	Access to MCP tools without installing local containers or creating and maintaining personal API keys	Makes the tools practical for engineers beyond the initial power users	My FastMCP servers and containers provided the services that were deployed
MCP proxy	One endpoint that routes to the underlying MCP servers	A single agent-harness configuration instead of separate configuration for every MCP server	Reduces setup friction and creates one place where telemetry and stronger access control can later be added	I was the main reviewer

5. 🧭 How I Turned a Personal Workflow into a Shared Engineering Initiative

Chapter summary: I developed and validated a workflow in my own engineering work, identified recurring needs across the team, taught what worked, established a coordinated initiative, and scaled useful solutions into shared capabilities.

Develop and validate my own agentic workflow. I educated myself, experimented with agents, and built practical solutions that improved my own software engineering workflow. Using those solutions in real work helped me understand which methods were useful and where the tooling still fell short.
Identify recurring problems across the engineering team. I spoke with engineers and listened to their frustrations. Several problems they described were ones I had already solved in my own workflow, revealing opportunities to make those solutions useful beyond my own setup.
Share and teach what worked. I transferred that knowledge through individual discussions, demonstrations, and organized knowledge-transfer sessions with groups of engineers. These sessions reached approximately 20 engineers; that is training reach, not verified active adoption.
Establish the initiative formally. I proposed agentic engineering capabilities during roadmap planning so the improvements could become a coordinated engineering initiative rather than disconnected personal practices.
Scale individual solutions into shared organizational capabilities. I developed shared infrastructure so useful skills and tools could reach engineers more reliably. The principle was to let engineers benefit from capabilities created and contributed by other engineers as well as from my own contributions.

6. 🏗️ Build Agent Tooling That Works Across Harnesses and Company Systems

The implementation contains two different stories. One is the content of the skills: which engineering problem each skill solves. The other is the infrastructure that distributes skills and connects agents to company systems. Keeping them separate makes the contribution of each deliverable visible.

6.1 Build Skills for Specific Engineering Problems

Skill or control	Problem addressed	Result	Ownership
Subagent routing	Expensive agents consumed the token allowance even for simple work	Routes simpler tasks to cheaper agents so the allowance lasts longer	Created by a colleague
Cross-harness session handoff	Work stopped or lost context when a harness reached its token limit	Transfers the existing conversation so work can continue in another harness	Created by me
Company-knowledge skills	Agents did not know which repositories and systems existed or how they related	Gives agents a map of where to look without searching the company from scratch	Created or contributed by me
Security guidance and deterministic hooks	Agents could read or expose sensitive data or take harmful actions during autonomous work	Combines behavioural guidance with controls that block prohibited actions	Contributed by me through shared instructions, skills, agent context, and hooks

This table will be extended as I add the remaining individual skills from my account.

6.2 Evolve Skill Distribution from Symlinks to the Skills MCP Server

First version: setup script and local symlinks.

The initial distribution combined Markdown skills with a setup script. The script symlinked the skills into the engineer's local agent harness so the agent could discover and load them.

Problem discovered: updates did not reach users reliably.

Users had to pull the latest Shared Agent Infrastructure repository and maintain the symlinks. Many installations became outdated. A skill configured for OpenCode also had to be configured again for Codex or another harness, so the available skills drifted between tools.

My solution: the Skills MCP server.

I built the Skills MCP server so shared skills could be served centrally rather than copied and synchronised separately for every user and harness. This allowed both my contributions and colleagues' skills to reach engineers through one distribution mechanism.

6.3 Build Custom MCP Tools for Company Systems

Problem: knowledge could identify a system but could not access it.

Skills could tell an agent where information existed, but they could not retrieve it. Greater autonomy required tools that connected the agent to the systems described by the skills.

My implementation: custom FastMCP servers.

I implemented custom FastMCP servers for systems including Bitbucket and Freshservice. I also added access to other company systems, including Jira, Datadog, and Databricks. These examples are not a complete inventory.

The Bitbucket code-search tool lets an agent search across all company repositories. It can trace API usage, schema and column references, consumers, and longer dependency chains across team and repository boundaries. This makes it possible to discover affected repositories that the engineer did not know existed and adjust an implementation before it creates a breaking change.

The custom Bitbucket and Freshservice tools predated comparable official vendor MCP servers by roughly half a year. The custom implementations were therefore required to obtain these capabilities at that time.

6.4 Move MCP Tools from Local Containers to Remote Services

First distribution: local Docker containers for power users.

I packaged the FastMCP servers in local Docker containers and published the containers to AWS Elastic Container Registry. The initial users installed Docker, pulled the containers, created the required API keys, passed those keys into the containers, and ran the services locally.

This early-adopter stage made the tools usable before a central deployment existed and allowed the capabilities to mature with a smaller group that could tolerate setup friction.

Problem discovered: credentials and containers blocked wider adoption.

Every engineer had to discover where to create each API key, store it safely, pass it correctly, renew it when it expired, and troubleshoot authentication failures. Keys could also be exposed to an agent accidentally. Local Docker installation and maintenance added another barrier.

Deployment goal: make MCP tools work without local setup ceremony.

A remotely deployed MCP service can hold a centrally managed, narrowly scoped credential, such as a read-only Bitbucket or Databricks credential, in the deployment's secret management. Engineers then connect to the remote endpoint without creating, storing, exporting, and renewing their own API keys or running local Docker containers.

Ownership: separate server implementation from production deployment.

I implemented the FastMCP servers, built their local Docker containers, and published those containers to the registry. My DevOps colleagues implemented the Kubernetes deployment that made the services remotely available and stored the shared credentials securely. Their work removed the remaining local setup barrier and enabled broader adoption.

6.5 Review and Establish the MCP Proxy

Problem: every MCP server required separate configuration.

Even after the services were remotely available, engineers would otherwise need to add and maintain a separate connection for every MCP server in each agent harness. This repeated setup was another adoption barrier: engineers wanted the tooling to work without spending hours configuring or troubleshooting it.

Solution: expose all MCP servers through one proxy.

The proxy bundles the underlying MCP servers behind one endpoint. An engineer configures a single connection in the agent harness and receives access to all of the services routed through it.

Delivered outcome: reduce setup to one connection.

The proxy makes the full MCP toolset substantially easier to adopt and keeps the harness configuration from growing with every new server.

Future capability: central telemetry and access control.

Because invocations pass through one place, the proxy creates an architectural point where usage telemetry could later be added. That logging has not yet been implemented. My DevOps colleagues also see the proxy as a foundation for stronger authentication, authorization, and federated authentication, and as a way to simplify aspects of Kubernetes deployment and management. I was not the specialist responsible for those deployment concerns, so I do not claim their detailed design as my own.

My contribution: main reviewer.

A teammate implemented the proxy. I was the main reviewer, worked deeply with the code, and contributed through detailed technical review rather than claiming authorship of the implementation.

7. 🧠 Capabilities I Can Apply to Future Projects

Chapter summary: I can apply the following capabilities to future agent-tooling projects.

7.1 Configure and Navigate Agent Harnesses

I developed deep practical knowledge of these harnesses:

Codex CLI
Codex desktop app
Claude Code CLI
Claude Code desktop app
OpenCode CLI

Across these tools, I know a large share of the keyboard shortcuts for fluent usage and navigation.

My hands-on configuration and troubleshooting experience covers:

MCP connections
Reasoning settings
Permissions
Hooks
Skills
Global instructions
Memory
Session history
Debugging

I understand the relevant settings and configuration files within each harness. I can help a team configure its workflows and investigate problems in its chosen tools.

7.2 Build Tools That Work Across Harnesses

My reusable integration and orchestration capabilities include:

Custom FastMCP servers: Give agents access to company systems through tools that work with compatible harnesses.
Subagent workflows: Use subagents within a broader engineering workflow.
Harness integration: Adapt configuration to the harness without rebuilding the underlying tool for each interface.

7.3 Make Agent Technology Usable and Adoptable

I learned to make working technology practical for other engineers through:

User discussions: Understand needs and identify difficulties in onboarding or everyday use.
Documentation: Explain how to start using a capability and work with it effectively.
Onboarding scripts: Automate setup steps that users would otherwise repeat manually.
Markdown skills: Make reusable knowledge and workflows available to agents.
Docker packaging: Package services so engineers have a practical way to run them.

I can use feedback from engineers to improve each part of that adoption path.

7.4 Engineer Reliable Skill and Tool Invocation

I gained practical experience with the mechanisms that help agents produce the intended outcome:

Skill triggers: Make the relevant skill discoverable in the situation where it is needed.
Skill instructions: Guide the agent through the task after the skill is loaded.
Tool selection: Connect the task to the tools needed to carry it out.
Hooks and harness configuration: Combine available controls with the workflow instructions.
Behavior debugging: Find where execution diverges from the intended workflow and refine the relevant mechanism.

This includes learning which skill descriptions and instructions work in practice and which fail to trigger or guide execution.

7.5 Design Workflow Loops and Session Continuity

My experience with longer-running agentic workflows includes:

Repeated initiation: Kick off the workflow again so work can continue beyond one interaction.
State management: Preserve the workflow state needed across sessions.
Context continuity: Carry forward the information needed to resume the task.
Autonomous progress: Keep subsequent work connected to the intended outcome and available tools.

I can apply these capabilities to let agents handle more intermediate work without requiring a person to restart and reconstruct every step.