My contributions to automating ~60 hours of manual database updates and service API/CLI calls per month

2. 🎯 Project Overview

3. 🧩 Why the Project Was Difficult: Before State

Chapter summary: Before automation, recurring requests required manual, potentially risky production-data updates; business intent and technical execution were split between people, causing repeated clarification loops; and the reduced operations team had no reliable end-to-end overview of the processes that still needed to run.

3.1 Manual, Risky Production-Data Updates

Meaning: Recurring Freshservice requests asked for changes to data managed by production services. Business teams described what should change in natural language and sometimes attached CSV or Excel files. Those inputs arrived in a completely different format from what the backend services accepted. An operations engineer therefore had to interpret the request, transform the data, and execute the change manually.

Evidence: A typical request followed this cycle. The exact tools and steps varied by request type and over time:

1. Submit a request: A business team opened a Freshservice ticket with the desired change and any supporting files.
2. Inspect the system: An operations engineer took over the ticket, checked the existing data, and determined the technical update needed.
3. Prepare and execute: The engineer reshaped the files or parameters and issued Java-service API calls or CLI commands. Earlier versions of some workflows also used direct production-database queries.
4. Investigate failures: Missing information, incorrect columns, or inconsistent data required diagnosis and corrections the engineer could make independently.
5. Clarify with the requester: If the missing information depended on business context, the engineer explained the issue, asked questions, and waited for a response.
6. Revise and retry: The engineer adjusted the input and tried again. Further errors could restart the same cycle.

Impact: Even routine updates consumed engineering capacity, and failures compounded the effort through repeated preparation and retries. Direct database queries were especially risky: unlike calls through the owning Java services, they bypassed the services' business-logic safeguards. The manual execution also lengthened the time between a request being submitted and the change being delivered.

3.2 Ambiguous Requests and Slow Clarification Loops

Meaning: Business stakeholders knew what they wanted to change and understood the business context, but lacked the tools and permissions to update production systems. Operations engineers had the technical access, but not necessarily the context needed to interpret a loosely specified request. The engineer had to translate the stakeholder's intent into an unambiguous operation the backend service could execute.

Evidence: For example, a requester might identify a record by its name, while the service required a unique ID. Names could refer to multiple records, and the requester might not know the ID. The engineer could not safely guess which record to modify and had to ask for more identifying information before proceeding.

Impact: This split made engineers intermediaries for both clarification and technical feedback. When an input failed validation or an operation returned an error, the requester could not see the feedback, correct the input, and retry independently. Instead, the engineer had to relay the issue, wait for an answer, revise the request, and try again. Every round trip consumed engineering time and delayed the change for the business stakeholder.

3.3 No End-to-End View of Operational Processes

Meaning: After the operations team was reduced, there was no reliable inventory of the recurring work that still needed to be done. The processes involved several business and technical teams, but nobody had a complete view of which workflows existed, who performed each step, or how tickets passed between teams.

Evidence: One remaining colleague with prior operations experience could give short daily walkthroughs of the tasks they were handling. These provided useful examples of individual procedures, but they could not reveal the full process landscape, its handoffs, or the total workload.

Impact: Without that overview, the team could not compare process frequency, manual effort, urgency, operational importance, or dependencies across teams. This made it difficult to decide where automation would have the greatest impact and which essential processes should be addressed first.

4. 🛠️ What I Built and the Impact It Had

4.1 Redirecting Automation Toward Higher-Impact Work

Meaning: I built an operational KPI pipeline and dashboard to measure where manual work was actually happening and help decide which processes were worth automating. Senior stakeholders had already agreed on a roadmap, but the selected processes were not necessarily the ones consuming the most operational time.

Evidence: By analyzing Freshservice ticket histories, including status changes and reassignment data, I compared recurring processes by frequency and manual effort. The original roadmap targeted work accounting for approximately 41 hours per quarter. My analysis revealed alternative processes accounting for approximately 770 hours per quarter that had been overlooked. These figures represent the manual workload available to target, not hours already saved or a guarantee of full automation. The analysis prompted the team to change its automation priorities. The discovery and methodology are described in more detail in the operational KPI case study.

Impact: Even eliminating all manual work in the original roadmap would have freed only about 14 hours per month (41 hours per quarter), far below the outcome the team eventually achieved. Redirecting the roadmap toward higher-impact processes made a much larger result attainable: the team's implemented automations now save approximately 60 hours of manual work per month. Those 60 hours are a realized team outcome, not hypothetical opportunity or savings attributable to me alone. My contribution: identifying and quantifying the higher-value work, then influencing which processes the team chose to automate.

4.2 Deterministic End-to-End Service-Request Automations

Meaning: I implemented deterministic workflows that execute recurring service requests through the team's existing automation architecture. Rather than requiring an operations engineer to interpret each input and manually perform the corresponding production-data update, these workflows provide a repeatable execution path for supported request types.

Evidence: Depending on the request type, structured Freshservice tickets and Google Sheets inputs pass through AWS API Gateway, EventBridge, Step Functions, and Python Lambda functions. The Lambda functions prepare and validate the input, then use a Python SDK to call the owning Java-service APIs, including endpoints I developed. I implemented workflows and integrations within this architecture rather than claiming to have designed the entire team-owned platform.

Impact: I estimate that the deterministic workflows I personally implemented save approximately 6 hours of manual engineering work per week. This is an estimate of savings attributable to my workflows, not an independently verified measurement. It is part of the team's approximately 60 hours of realized monthly savings, not an additional amount to add on top. Automating the supported requests also reduces the need for repetitive manual execution and its associated handoffs.

4.3 Agent-Assisted Recovery of Failed Requests

Meaning: I assembled agent tooling to help engineers investigate and recover service requests that failed during automation. The aim was not to give an agent unrestricted access to production changes, but to let it gather context, identify possible corrections, and prepare the next attempt for human review.

Evidence: I built a custom Freshservice MCP server using FastMCP and connected the agent to other systems through configured MCP integrations and my own production-grade Java-service read/write CLI. A failed-request recovery workflow can:

1. Read the Freshservice request, including its comments and attached files.
2. Investigate the failure using context from connected systems, browser interactions, and Java-service CLI operations.
3. Prepare a corrected Google Sheet for the automation's expected input format.
4. Present the correction to an engineer; only with human approval can the agent trigger another execution attempt.

I used AGENTS.md instructions, Agent Skills, and operating procedures to connect these tools into multi-step workflows. This is local agent-assisted tooling, not a separate, centrally deployed production service.

Impact: The approach can reduce the manual investigation, file correction, and cross-system coordination required when an automated request fails, while keeping approval of production-affecting retries with a human. I am not attributing a measured share of the team's 60 hours of monthly savings to this local workflow.

5. 🔧 From Undocumented Manual Processes to Tested End-to-End Automations

Implementation summary: Before writing code, I reconstructed the manual process with the people who performed or requested it. I then changed the relevant components across repositories, validated the complete workflow in a test environment, and added automated system tests to guard against regressions.

The exact changes varied by process, but my typical implementation sequence was:

1. Learn and document the manual process. I met with business stakeholders and the remaining operations engineer to understand the request, its business rules, and the individual steps used to complete it manually. I worked through those steps myself to understand the end-to-end behavior and documented the process in Markdown.
2. Implement the required behavior in the responsible components. I usually started with the core operation. Depending on the use case, that meant adding a Java-service API endpoint for a write operation the service did not previously expose, modifying existing business logic, or changing application behavior in a Python Lambda. I then connected the relevant Java-service, Python SDK, and Lambda components.
3. Coordinate changes across repositories. A complete workflow often required changes in multiple repositories and more than one Lambda. I developed the interdependent changes together rather than merging an isolated component before the integration worked.
4. Verify the integrated workflow manually. I deployed the compatible changes to the test environment and executed manual system tests to confirm that the components interacted correctly end to end.
5. Review, merge, and protect against regressions. After the integrated behavior worked in the test environment, I opened and merged the relevant pull requests across repositories. I then added automated system tests to capture the expected behavior and detect regressions.

This was how I approached the deterministic workflows described in Section 4.2, rather than a claim that every automation required exactly the same code changes.

6. 🧰 Skills and Capabilities I Developed

The project developed three complementary areas of technical capability:

6.1 Cloud & Infrastructure

• AWS Serverless Stack: AWS Lambda (Python request processing and integrations), AWS Step Functions (multi-step orchestration), Amazon API Gateway (API entry points), and Amazon EventBridge (event routing).
• Identity & Secrets Management: Amazon Cognito for user management and AWS Secrets Manager for managing integration secrets.
• Terraform: Defining and managing AWS infrastructure as code.

6.2 Backend & Testing

• Python and Pydantic: Implementing automation logic and validating structured inputs.
• Java services and APIs: Extending service endpoints and integrating Python workflows with the owning Java services rather than bypassing their business logic.
• Production-grade Java-service CLI: Building a read/write command-line interface for Java-service operations that engineers can use directly and agents can invoke as a tool.
• Testing across the pyramid: Unit, integration, and system tests, including BDD scenarios, using Python, pytest, unittest, unittest.mock, AWS-service mocks, and tests against integrated systems.
• Hexagonal architecture: Applying ports-and-adapters concepts to separate business logic from infrastructure and external integrations.

6.3 Agentic AI & Tooling

• FastMCP / custom MCP development: Building a Freshservice MCP server myself to expose service-management operations to an agent.
• Configured MCP integrations: Connecting existing MCP integrations for Databricks, Google Sheets, AWS, and browser interaction (Browser-Use MCP); later configuring the official Freshservice integration for colleagues. I built the custom Freshservice MCP server, not these existing integrations.
• Agent instructions and skills: Using AGENTS.md, reusable Agent Skills, and SOPs to guide how agents select tools, gather context, and chain actions into operational workflows.