# Solved Systems: full text > We build custom AI automation inside your Microsoft 365 tenant. Houston AI automation firm. Engineers architect, code, and implement the systems inside the client's own Microsoft environment. You keep the code. Every indexable page of https://www.solvedsystems.com in one document, in sitemap order. Short index: https://www.solvedsystems.com/llms.txt · Sitemap: https://www.solvedsystems.com/sitemap.xml Any single page is also available as markdown by requesting its own URL with `Accept: text/markdown`. # Solved Systems: AI workflow automation for growing businesses > https://www.solvedsystems.com/ We build custom AI automation inside your Microsoft 365 tenant. Houston AI automation firm. Engineers architect, code, and implement the systems inside the client's own Microsoft environment, and clients keep the code. ## What we do - **Analyze**: map your workflows, identify automation opportunities, and design AI-powered solutions for your specific business. - **Build**: create custom automation using AI, APIs, and smart integrations built for your operations. - **Optimize**: implement, train your team, and continuously improve your workflows. ## Services - AI workflow automation: custom AI that handles repetitive tasks, routes information, and applies your business rules. - Custom business automation: systems that connect your tools and eliminate data silos. - Process intelligence: analytics that reveal bottlenecks and track performance. - Automation strategy and support: ongoing optimization, training, and guidance. ## How an engagement runs 1. Workflow analysis 2. Solution design 3. Build and test 4. Deploy and train 5. Continuous improvement ## Proof A mid-size oil and gas company ran daily operations across 40+ spreadsheets; data entry consumed 15+ hours weekly. We built an AI-powered workflow system that collects, processes, and routes operational data and now handles 200+ daily tasks. See [case studies](https://www.solvedsystems.com/projects). ## Start here - [Pricing](https://www.solvedsystems.com/packages): Starter $7,500/mo, Growth $10,000/mo, Enterprise custom. Month to month, cancel anytime. - [About the team](https://www.solvedsystems.com/about) · [How we build](https://www.solvedsystems.com/tech) · [Workflows we automate](https://www.solvedsystems.com/automate) · [Blog](https://www.solvedsystems.com/blog) --- # Workflows we automate > https://www.solvedsystems.com/automate The specific processes Solved Systems builds automation for, and the Microsoft components each one runs on. - [Automate employee onboarding and compliance deadlines](https://www.solvedsystems.com/automate/employee-onboarding-paylocity): Route new hire paperwork automatically and stop tracking compliance deadlines by hand. Built on Paylocity, Power Automate, and SharePoint, inside your own Microsoft environment. - [Automate invoice and contract intake](https://www.solvedsystems.com/automate/invoice-intake): Stop keying invoices by hand. We read the document, validate the fields, and route the approval, inside your own Microsoft environment. Built on Azure AI Document Intelligence and Logic Apps. - [Automate upstream production reporting](https://www.solvedsystems.com/automate/upstream-production-reporting): Replace spreadsheet-based oil and gas production reporting with automated SCADA and ERP data collection, validation, routing, and role-based dashboards. - [Integrate manufacturing inventory systems without replacing the legacy ERP](https://www.solvedsystems.com/automate/inventory-system-integration): Connect manufacturing inventory across a legacy ERP, WMS, and procurement workflow with Azure Functions, event-driven sync, and AI reconciliation. --- # Pricing and packages > https://www.solvedsystems.com/packages Monthly automation subscriptions. Month to month, cancel anytime. Clients own the code and flows. - **Starter**, single automation development: $7,500 per month. - **Growth**, multi-workflow development: $10,000 per month. - **Enterprise**, unlimited automation capacity: custom pricing. --- # Case studies and products > https://www.solvedsystems.com/projects Automation systems built for oil and gas, manufacturing, financial services, and SaaS operations. Client identities are confidential; results are from specific engagements, not predictions. - [Upstream Production Workflow Automation](https://www.solvedsystems.com/projects/upstream-production-workflow-automation) (OIL & GAS OPERATIONS): Mid-size operator managing daily operations across 40+ spreadsheets. We built an AI-powered workflow system that automatically collects, processes, and routes operational data. - [Inventory Management System Integration](https://www.solvedsystems.com/projects/inventory-management-system-integration) (MANUFACTURING): Connected legacy ERP system with modern AI analytics platform, eliminating manual data entry and creating real-time inventory visibility. - [Document Processing Automation](https://www.solvedsystems.com/projects/document-processing-automation) (FINANCIAL SERVICES): AI-powered invoice and contract processing system that handles document intake, data extraction, and routing—eliminating 72-hour turnaround times. - [Customer Onboarding Automation](https://www.solvedsystems.com/projects/customer-onboarding-automation) (SAAS OPERATIONS): Built intelligent onboarding workflow that automatically provisions accounts, sends documentation, and tracks completion—scaling from 10 to 100+ customers monthly. Products: PatchOps, Exempt.Land, HR Sync, and VIZUAL. --- # How we build > https://www.solvedsystems.com/tech Solved Systems qualifies work before choosing tools. A process must be stable enough to define, and its expected payback must justify the build effort. The chosen workflow is broken into bounded tasks handled with rules and code, APIs and integrations, task-specific AI, or human review as needed. Existing source systems remain the systems of record. Clients own the code and flows. ## Technology - Microsoft 365, Azure, Power Platform, Power BI, Logic Apps, Data Factory. - API integrations with Salesforce, QuickBooks, Asana, Slack, Shopify, HubSpot, and Paylocity. - Custom code and low-code applications when the workflow calls for them. --- # About Solved Systems > https://www.solvedsystems.com/about We build custom AI automation inside your Microsoft 365 tenant. Houston AI automation firm. Engineers architect, code, and implement the systems inside the client's own Microsoft environment, and clients keep the code if they leave. ## Team - **Jeff Bernard**, Founder and Automation Architect. Systems engineering background; builds, not just consults. - **Martin Rodriguez**, Full Stack Engineer. React, Next.js, and Node.js; Computer Science at the University of Houston. ## Products PatchOps (oil and gas infrastructure monitoring), Exempt.Land (guided Texas property-tax workflows), HR Sync (onboarding and compliance tracking), and VIZUAL (a low-code app builder for the Corva platform). Strongest experience is in oil and gas upstream production, with work in manufacturing, financial services, and SaaS operations. --- # Solved Systems blog > https://www.solvedsystems.com/blog Strategy, implementation, and lessons from building AI workflows for operations teams. - [Pricing AI in Barrels: Why We Denominate Tokens in Energy](https://www.solvedsystems.com/blog/pricing-ai-in-barrels-why-we-denominate-tokens-in-energy): We built a live ticker that converts commodity prices into AI tokens. Here's the methodology behind it — and why the connection between energy markets and AI compute is more than a gimmick. - [How We're Using Reinforcement Learning Principles to Build Better Oil & Gas Tools](https://www.solvedsystems.com/blog/how-we-re-using-reinforcement-learning-principles-to-build-better-oil-gas-tools): PatchOps is building a connector eval system that applies the same task-and-verify loop behind modern AI training to continuously improve the quality of our MCP tools for the energy industry. - [Paylocity to Active Directory: Automating Employee Lifecycle Sync for Mark-Taylor Residential](https://www.solvedsystems.com/blog/automating-employee-lifecycle-management-hybrid-identity-sync-for-mark-taylor-residential): How we built an automated employee lifecycle system that bridges Paylocity HR data with both cloud and on-premises identity infrastructure, eliminating manual IT overhead and notification noise. - [How We Made Keyframe Editing Feel Like Moving a Camera](https://www.solvedsystems.com/blog/how-we-made-keyframe-editing-feel-like-moving-a-camera): We replaced nine property tracks and manual number entry with a visual framing overlay that lets you drag a rectangle on the video preview to control zoom and pan keyframes. - [How We Replaced Hardcoded Video Templates with AI-Generated Layouts](https://www.solvedsystems.com/blog/replaced-hardcoded-video-templates-ai-generated-layouts): We had 48 hardcoded Remotion templates that made every client's video look the same. Here's how we replaced them with an AI-driven scene description language that treats layout as data — and never wrote another template again. - [How We Cut Token Consumption by 98% Moving from Tool Calling to Code Execution](https://www.solvedsystems.com/blog/cut-token-consumption-98-percent-tool-calling-to-code-execution): Every MCP tool call was flooding our context window with raw JSON. By shifting to server-side code execution, we reduced token consumption by 95-99% across our energy industry API integrations. - [How We Automated 200+ Daily Tasks for an Oil & Gas Company](https://www.solvedsystems.com/blog/automated-200-tasks-oil-gas): From 40+ manual spreadsheets to intelligent automation. A case study in systematic workflow transformation. --- # Contact Solved Systems > https://www.solvedsystems.com/contact Tell us the system. We will quote a build. Describe the workflow, the systems it touches, and where the work gets stuck. - Form: https://www.solvedsystems.com/contact - Email: info@solvedsystems.com - Phone: (713) 702-7974 - Location: Houston, Texas --- # Privacy policy > https://www.solvedsystems.com/privacy What solvedsystems.com collects: information you send through the contact or workflow inquiry forms (name, email, company, message), Google Analytics 4 usage data, and campaign tags when you arrive from an ad. Form submissions are delivered by email and are not written to a database on this site. Full policy: https://www.solvedsystems.com/privacy. --- # Automate employee onboarding and compliance deadlines > https://www.solvedsystems.com/automate/employee-onboarding-paylocity Onboarding does not fail because HR is careless. It fails because a deadline is not a task until somebody owns it. We build the routing, so the documents move themselves and the deadlines escalate on their own. ## The pain - The offer goes out from one system. The I-9 waits in another. - IT learns the start date in a standup, and orders the laptop that afternoon. - Somebody keeps a spreadsheet of certification expiry dates, and hopes. - Every step has a person. No step has an owner. ## Where it breaks ### An inbox cannot escalate A forwarded email is a request with no owner and no clock. It sits until someone remembers it, and the person who remembers is rarely the person who is accountable for the deadline. ### The checklist is not the system Most onboarding lives in a document that describes what should happen. Nothing enforces it. When a step is skipped, nobody finds out until day one, when the new hire has no laptop and payroll has no I-9. ## What we build it with - **Paylocity**: Employee records stay the source of truth. We extract employee data, process payroll information, and sync HR records across your systems automatically. - **Power Automate**: A new hire record is the trigger. The document requests go out, the countdown starts, and each request knows who owns it and when it is late. - **SharePoint**: Documents land where they belong, with the right permissions, named the same way every time. No shared drive, no attachments in an inbox. - **Microsoft Teams**: Escalation happens where people already are. When a deadline is close, the nudge goes to the person holding the document, not to a distribution list. ## When this is not a fit - You hire two or three people a year. The routing costs more than the chasing. - Your onboarding steps change every quarter. Stabilize the process first, then automate the version that survives. - What you actually want is a reminder. A reminder is cheap. Routing is for the deadline that outlives the meeting where it was assigned. ## FAQ ### Do we have to move off Paylocity? No. Paylocity stays the system of record. We integrate with it. The automation runs alongside your existing HR stack, not instead of it. ### Where does the data live? Inside your own Microsoft environment, on licenses you already pay for. It does not move to a platform we control, because there is not one. ### What happens if we stop working with you? You keep everything. The flows, the SharePoint structure, the code. It runs in your tenant under your accounts, so it keeps running without us. ### How long does a build like this take? It depends on how many systems have to talk to each other. Show us the current onboarding flow and we will scope the work before we quote the build. ### How do we get a build quote? Tell us how onboarding works today and where it breaks down. We will review the system, confirm whether it is ready to automate, and quote the build. --- # Automate invoice and contract intake > https://www.solvedsystems.com/automate/invoice-intake The expensive part of an invoice is not the reading. It is the waiting. An invoice spends most of its life in queues: waiting to be opened, waiting to be keyed, waiting for an approver who does not know it exists. ## The pain - The invoices arrive by email. Somebody opens every one. - Somebody keys the fields into the accounting system, twice if there is a contract attached. - Then somebody chases the approver, who has not seen it. - Three jobs, and none of them is the job. ## Where it breaks ### Re-keying is where the errors are Every hand that touches a number is a chance to transpose it. The errors do not surface in accounts payable. They surface at month end, in a reconciliation nobody budgeted for. ### Approval is a search problem When an approval lives in an inbox, finding out where a document sits means asking a person. Multiply that by a few hundred documents a month and the chasing becomes somebody’s actual job. ## What we build it with - **Azure AI Document Intelligence**: The reading. Extraction straight from the document, whether it arrived as a scan, a PDF, or a photograph of a scan. - **Logic Apps**: The validation and the routing. Fields are checked before a human sees them, and the approval finds the approver instead of waiting to be found. - **SharePoint and Teams**: The document lands in one place, and the approval happens where people already work. Anyone can see where a document sits without asking. - **Your accounting system**: We integrate with what you already run, QuickBooks included. The ledger stays the system of record. ## Published results a financial services client - **500** invoices and contracts a month - **94%** accuracy rate - **3 days to under 4 hours** turnaround We built intake for a financial services client with Azure AI Document Intelligence and Logic Apps, inside their own Microsoft tenant. The system reads the document, validates the fields, and routes the approval. ## When this is not a fit - You process a few dozen documents a month. A person reading them is cheaper than a system that reads them. - Every document has a different shape and arrives once. Extraction needs a pattern to learn. - The document genuinely needs a person. Some do. The system should know which ones, and hand them over rather than guess. ## FAQ ### What accuracy should we expect? We will not quote you a number before we have seen your documents. What we can say is that validation matters more than extraction. When the system flags the right exceptions, people stop re-checking everything it touches. ### Does our data leave our systems? No. It runs inside your own Microsoft environment, on licenses you already pay for. ### Do we keep the code? Yes. Every automation, integration, and flow we build is yours. Month to month, cancel anytime, and it keeps running without us. ### What about documents the system cannot read? They go to a person. We always keep a human lane, and the system is built to know which documents belong in it. ### How do we get a build quote? Tell us how invoices arrive, where the data goes, and who handles exceptions. We will scope the intake workflow and quote the build. --- # Automate upstream production reporting > https://www.solvedsystems.com/automate/upstream-production-reporting A production report should describe what is happening now. When field data is copied through spreadsheets and inboxes first, every handoff makes the report older. We build the collection, validation, and routing so each team works from the same current data. ## The pain - Field readings, well tests, and maintenance logs arrive in different formats. - Operations staff copy the same values between spreadsheets before reporting can begin. - Supervisors wait for emailed rollups while the underlying production data keeps changing. - Engineers, maintenance teams, and executives end up making decisions from different versions. ## Where it breaks ### Copy-paste is not a data pipeline A spreadsheet can hold a production number, but it cannot reliably collect, validate, and route that number across every team that needs it. Manual consolidation turns reporting into a recurring operations task. ### A delayed report creates several versions of the truth When field data reaches each audience on a different schedule, the production engineer, maintenance team, and executive rollup stop agreeing. The meeting becomes a reconciliation exercise before it can become a decision. ## What we build it with - **SCADA and field inputs**: Field sensors, existing SCADA infrastructure, and manual entry forms feed one collection layer instead of another round of spreadsheet copying. - **Azure data pipeline**: Event-driven processing moves incoming operational data through a shared workflow and connects it with the existing ERP through APIs. - **Validation layer**: Incoming values are checked against known formats and historical patterns so anomalies can be flagged before they reach a decision-maker. - **Role-based dashboards**: Production, maintenance, and executive views receive the data relevant to each team without separate reporting chains. ## Published results an upstream oil and gas operator - **40+** spreadsheets replaced - **15+** hours saved weekly - **200+** tasks automated daily We replaced a mid-size operator's spreadsheet-based production workflow with automated collection, validation, and reporting connected to its existing SCADA and ERP systems. ## When this is not a fit - The source data changes definition from one shift to the next. Agree on the operating definitions before automating the report. - The problem is one isolated spreadsheet used by one person. Integration costs more than a stable manual handoff at that scale. - The existing SCADA or ERP data cannot be accessed reliably. Fix the source connection before building reporting on top of it. ## FAQ ### Do we have to replace our SCADA or ERP system? No. The published engagement connected to the operator's existing SCADA infrastructure and ERP through APIs. The workflow sits between the systems that already run the operation. ### What happens to manually entered field data? Manual entry forms can feed the same collection layer as sensor data. The goal is one validation and routing path, even when not every source is automated. ### How is production data validated? Validation rules can check formats and compare incoming values with historical patterns. Exceptions should be flagged for review instead of silently becoming part of the report. ### Can each team have a different view? Yes. The workflow can route production data, maintenance alerts, and executive rollups to role-based dashboards without maintaining separate data copies. ### How do we get a build quote? Show us how one production report moves from the field to its final audience. We will scope the collection, validation, and routing work, then quote the build. --- # Integrate manufacturing inventory systems without replacing the legacy ERP > https://www.solvedsystems.com/automate/inventory-system-integration Inventory does not need another place to be entered. It needs one change to reach every system that depends on it. We build the integration layer between the legacy ERP, warehouse workflow, and procurement process so people reconcile exceptions instead of entire datasets. ## The pain - Warehouse staff update the WMS, then send the same information to procurement. - Procurement maintains a spreadsheet because the ERP does not reflect the current count. - Discrepancies surface days later, after a purchasing or stocking decision has already been made. - Replacing the legacy ERP would cost more and disrupt more than connecting it. ## Where it breaks ### Manual reconciliation becomes the system of record When three systems disagree, the spreadsheet maintained between them becomes the only place that explains the differences. The business starts depending on a person to keep its inventory state coherent. ### Replacement is not the only integration strategy A legacy ERP can remain the operational backbone while an integration layer translates its data for the WMS and procurement workflow. Modernization does not have to begin with a disruptive rip-and-replace project. ## What we build it with - **Legacy ERP and WMS bridge**: Custom middleware translates the ERP's existing format and the warehouse system's API into a shared inventory model. - **Azure Functions**: Event-driven triggers process inventory changes without requiring either operational system to be replaced. - **Message queue**: Updates move between systems that run on different schedules, so one slow connection does not stop the rest of the workflow. - **AI reconciliation**: A reconciliation model continuously compares the systems, automatically resolving minor discrepancies and flagging significant ones for human review. ## Published results a regional manufacturer - **3** systems unified - **89%** less manual data entry - **Same-day** inventory accuracy We connected a manufacturer's legacy ERP, warehouse management system, and procurement workflow through an Azure Functions integration layer instead of replacing the existing systems. ## When this is not a fit - One system already owns every inventory change and the others can be retired. Consolidation may be simpler than an integration layer. - Product identifiers and units do not match across systems. Define the shared inventory model before automating synchronization. - The legacy system has no stable export, API, or event source. Establish a reliable connection before promising real-time updates. ## FAQ ### Do we have to replace our legacy ERP? No. The published manufacturing engagement kept the legacy ERP and connected it with the WMS and procurement workflow through a translation layer. ### Can a procurement spreadsheet be part of the integration? Yes, when its fields and ownership are defined. The integration should turn it into a structured input or output instead of leaving it as a separate manual reconciliation process. ### How do systems with different update schedules stay in sync? An event-driven workflow and message queue can buffer and route changes between systems without assuming that every connection updates at the same speed. ### What happens when inventory counts disagree? The reconciliation layer compares data across systems, automatically resolves minor discrepancies, and sends significant differences to a person for review. ### How do we get a build quote? Show us how one inventory update moves across the ERP, WMS, and procurement process. We will scope the integration layer and quote the build. --- # Pricing AI in Barrels: Why We Denominate Tokens in Energy > https://www.solvedsystems.com/blog/pricing-ai-in-barrels-why-we-denominate-tokens-in-energy Jeff Bernard · Technology · 2026-03-17 We built a live ticker that converts commodity prices into AI tokens. Here's the methodology behind it — and why the connection between energy markets and AI compute is more than a gimmick. ## The Question What does a barrel of oil have to do with artificial intelligence? At PatchOps, we serve oil and gas professionals who use AI daily — querying well data, analyzing production reports, running geological models. These are people who think in barrels, MCFs, and MMBtus. When we added a live energy ticker to the platform, we asked a simple question: **what if we showed commodity prices denominated in AI tokens?** The idea sounds like a gimmick. But the more we dug into it, the more we found a real and tightening relationship between energy markets and AI compute costs. ## The Methodology Our ticker pulls real-time prices for three commodities — WTI Crude, Brent Crude, and Henry Hub Natural Gas — and divides each by a blended average token price to produce a simple conversion: **how many AI tokens does this commodity's dollar value represent?** The blended token price isn't hardcoded. We pull live pricing from OpenRouter's public API across five major models (Claude Sonnet, Claude Haiku, Claude Opus, GPT-4o, GPT-4.1), weight them by approximate market usage share, and blend input and output costs at a 75/25 ratio — reflecting that most tokens in a typical AI interaction are prompt and context, not generation. The result is a single number, updated hourly: the current average cost of one million AI tokens. At the time of writing, that's roughly **$6 per million tokens**. Divide WTI at $70/bbl by $6/M tokens and you get approximately **11.7 million tokens per barrel**. That's about 8,000 full-length conversations with a frontier AI model — for the price of one barrel of crude. ## Testing the Assumption: Is AI Actually Tied to Energy? The instinct that AI and energy are linked isn't just vibes. The data supports it, and the trend line is steep. ### The Scale of AI's Energy Appetite U.S. data centers consumed **183 terawatt-hours** of electricity in 2024 — more than 4% of total national consumption. Lawrence Berkeley National Laboratory projects this will grow to **325–580 TWh by 2028**, or 6–12% of all U.S. electricity. The Electric Power Research Institute estimates data centers could consume up to 9.1% by 2030. These aren't training runs. **Inference — the act of generating tokens in response to user queries — accounts for more than 90% of AI's total power consumption.** Every token your AI assistant produces has an energy cost. ### Natural Gas Is the Marginal Fuel Where does the electricity come from? Increasingly, natural gas. Morgan Stanley projects that natural gas will meet roughly one-fifth of the world's new power needs (excluding China), with gas investments hitting record highs since 2024. When a new data center comes online in Texas or Virginia, the marginal electron powering it often comes from a gas turbine. This creates a direct, if lagged, transmission mechanism: **Henry Hub price → electricity cost → data center operating expense → pressure on token pricing**. Today, energy is a small fraction of what you pay per token — compute hardware, R&D amortization, and margin dominate. But as AI scales and efficiency gains plateau, energy's share of the cost stack will grow. ### Efficiency Is Improving — But Demand Is Growing Faster Hardware efficiency is advancing rapidly. Modern H100 GPU clusters achieve roughly **10x better token-per-joule efficiency** than the V100/A100 hardware of two years ago. A single kilowatt-hour can now deliver over 10 million tokens on optimized infrastructure. But demand is outrunning efficiency gains. Global AI inference volume is doubling faster than hardware efficiency improves. The net result: total energy consumption by AI continues to climb despite each individual token getting cheaper to produce. ## Why This Matters for Energy Professionals If you work in oil and gas, this framing offers three insights: **1. Your industry is funding the AI revolution.** The molecules you produce are, through the electricity grid, being converted into tokens. Natural gas doesn't just heat homes and run turbines — it powers the inference engines that are reshaping every industry, including yours. **2. AI demand is a new structural driver for energy markets.** Data center load is becoming a meaningful component of electricity demand forecasts. Utilities are signing long-term power purchase agreements with hyperscalers. This is new, persistent, baseload demand — not seasonal, not cyclical. **3. The correlation will tighten.** Today, token prices are mostly set by competition, hardware amortization, and margin strategy. But as AI scales into the hundreds-of-terawatt-hours range, energy costs will become a larger share of the cost stack. When that happens, token prices and energy prices will move more closely together — much like how aluminum smelting costs track electricity prices. ## The Ticker Our energy ticker runs across the top of the PatchOps platform, updating commodity prices every 15 minutes and token prices every hour. It's a small thing — a scrolling strip of numbers. But it encodes a thesis: **that the energy industry and the AI industry are converging, and the professionals who understand both will have an edge.** Next time you see WTI at $70, think about the 11.7 million tokens embedded in that barrel. The energy transition isn't just about solar panels and EVs. It's about the invisible conversion of hydrocarbons into intelligence. --- # How We're Using Reinforcement Learning Principles to Build Better Oil & Gas Tools > https://www.solvedsystems.com/blog/how-we-re-using-reinforcement-learning-principles-to-build-better-oil-gas-tools Jeff Bernard · Engineering · 2026-03-17 PatchOps is building a connector eval system that applies the same task-and-verify loop behind modern AI training to continuously improve the quality of our MCP tools for the energy industry. The models powering AI coding assistants got dramatically better over the last two years. The reason isn't bigger datasets or more parameters — it's reinforcement learning. Give a model a task, let it try, check whether the output actually works, and use that signal to get better. Repeat millions of times. Code is the ideal domain for this because verification is cheap and unambiguous. Does it compile? Do the tests pass? That binary signal — pass or fail — is all you need to close the loop. At PatchOps, we're not training models. We're building the tools that models use — MCP connectors that give AI agents access to real-world data across the energy industry. Regulatory filings from the Texas Railroad Commission. Well records from WellDatabase. Production analytics from Corva. Market data from ERCOT, CAISO, and EIA. Environmental monitoring from USGS, EPA, and NOAA. Pipeline intelligence from Enverus. Fleet tracking from Samsara and Geoforce. Over 50 connectors and growing. The same RL principle applies to all of them: **if you can define what "correct" looks like and verify it automatically, quality only goes up.** ## The Problem: Scale Creates a Quality Challenge When you have a handful of tools, you can test them manually. When you have hundreds of tools spread across 50+ connectors — each with different APIs, auth models, data formats, and domain semantics — manual testing doesn't scale. Every connector has its own quality questions: - Does WellDatabase's `searchWells` return the fields an AI agent needs — well name, API number, operator, coordinates, lateral length? - Does Corva's `getWellDetails` include real-time drilling data when a well is active? - Does ERCOT's `getGridConditions` return current load data within 5 seconds? - Does the RRC connector handle 977,000+ well records without timeouts? - Does Enverus return production data with the right units and date formats? - Do environmental connectors (USGS water, EPA air quality, NOAA weather) return valid GeoJSON? - When you add a new dataset to one connector, did you break another? Without a systematic way to answer these questions across *every* connector, you're relying on user reports to find problems. That's reactive. We wanted to be proactive. ## The Solution: Eval Suites for Every Connector We built a connector eval system that borrows directly from the RL playbook: **task + verifier**, pointed at our tools instead of at model outputs. An eval suite is a collection of test cases grouped by connector. Each case specifies: - **A tool to call** — e.g., `searchWells` on WellDatabase, `getGridConditions` on ERCOT, `searchInspections` on RRC - **Input arguments** — the exact parameters an AI agent would pass - **Assertions** — verifiable claims about what the response should look like The assertion engine supports nine verification types that cover the patterns we care about across all connectors: ``` no_error — the tool call succeeded has_data — a path in the response has non-empty data field_exists — a specific field exists (e.g., data[0].wellName) field_equals — a field matches an expected value field_contains — a field contains a substring count_gte — an array has at least N items count_lte — an array has at most N items response_time_ms — response completed within a time budget response_shape — response has the expected top-level keys ``` When you hit "Run All," each case executes against the real connector — same code path as a Claude or ChatGPT user calling the tool. The assertion engine checks every claim and records pass/fail with detailed diagnostics. ## What This Looks Like Across the Platform Every connector category has its own quality concerns. The eval system handles all of them with the same framework. ### Oil & Gas Data Connectors > **WellDatabase** — search returns wells with complete metadata; operator queries match known operators; production data has valid numeric fields > > **Corva** — real-time drilling data includes WIT streams; well details have survey and completion data; rig assignments resolve correctly > > **Enverus** — production queries return data with correct units; lease records include all required regulatory fields > > **RRC** — 37 tools covering wells, permits, inspections, pipelines, gas plants, and production across 977K+ records ### Energy Markets > **ERCOT** — grid conditions return current load and frequency; LMP prices have valid node identifiers; fuel mix totals sum correctly > > **CAISO** — day-ahead prices return for requested dates; renewable curtailment data includes MW values > > **EIA** — petroleum supply data matches known reporting periods; natural gas storage reports have regional breakdowns ### Environmental & Geospatial > **USGS Water** — streamflow queries return valid gauge data with timestamps; site lookups resolve by HUC code > > **EPA / AirNow** — air quality index returns current readings; monitoring station data includes lat/lng > > **NOAA / NWS** — forecast data returns for valid coordinates; historical weather has temperature and precipitation fields > > **Wetlands / Floodzone / Soils** — spatial queries return valid GeoJSON with proper feature properties ### Enterprise & Productivity > **Snowflake** — query execution returns results with correct column types; schema introspection lists all tables > > **Samsara / Geoforce** — fleet queries return vehicle positions with timestamps; geofence lookups resolve correctly > > **GitHub** — repository queries return valid issue and PR data; project board cards have correct status fields The same nine assertion types work everywhere. `has_data` verifies a Corva drilling response just as well as an EPA air quality reading. `response_shape` validates an ERCOT grid response the same way it validates a WellDatabase search. ## The Feedback Loop The real power isn't in running evals once — it's in the loop they create across the entire platform: Write Eval Run It It Fails Fix & Pass The eval loop: write a test, run it, see it fail, fix the handler, watch it pass. Repeat — across every connector. Today this loop is manual — you see a failure, open the handler code, fix it, re-run. But the architecture supports automation at every step. A failing eval can be fed to an AI agent along with the handler source code to propose a fix. Evals can run on every pull request so connector quality never regresses. When we recently audited our RRC connector, the eval system immediately surfaced that 26 of 37 tools returned empty results (ETL still loading), 2 had a date parsing bug, and 9 were fully operational. That's the kind of visibility you need when you're scaling a platform — not guessing, knowing. ## Where We're Headed We're building eval suites for every connector on the platform, starting with the highest-traffic ones and expanding outward. The roadmap: - **CI-gated evals** — every PR that touches a connector handler must pass its eval suite before merging. Break a WellDatabase search? The PR is blocked. - **AI-assisted diagnosis** — failing evals automatically generate fix proposals by analyzing the handler code against the expected output - **Coverage dashboard** — track which connectors and tools have evals, which don't, and prioritize the gaps - **Cross-connector consistency** — ensure that patterns like pagination, error handling, field naming, and GeoJSON output are consistent across all 50+ connectors - **Regression detection** — when an upstream API changes (ERCOT updates their schema, WellDatabase adds a field), the eval catches it before users do **The insight from RL applies directly:** if you can define what "correct" looks like and check it automatically, you can improve continuously. We're applying that principle to every connector on the PatchOps platform — oil and gas, energy markets, environmental data, enterprise tools — and the result is an ecosystem of AI tools that gets more reliable with every iteration. The eval system is live on PatchOps today. If you're building MCP tools for any industry and want to see how assertion-based verification can improve your connector quality, we'd love to talk. --- # Paylocity to Active Directory: Automating Employee Lifecycle Sync for Mark-Taylor Residential > https://www.solvedsystems.com/blog/automating-employee-lifecycle-management-hybrid-identity-sync-for-mark-taylor-residential Jeff Bernard · Case Studies · 2026-03-03 How we built an automated employee lifecycle system that bridges Paylocity HR data with both cloud and on-premises identity infrastructure, eliminating manual IT overhead and notification noise. ## The Challenge Mark-Taylor Residential manages a large workforce across multiple properties and legal entities. Like many organizations that have grown organically, their IT infrastructure spans both cloud services (Microsoft Entra ID, Microsoft 365) and on-premises Active Directory — a hybrid identity model that adds real complexity to everyday operations. When an employee is hired, changes roles, goes on leave, or is terminated, those changes originate in their HR system (Paylocity). But the downstream impact touches multiple systems: cloud identities, on-prem domain accounts, email, licensing, and manager notifications. Before our engagement, much of this was either manual or handled by a first-generation automation that had grown brittle over time. ## Key Problems We Solved ### Notification Flooding Routine HR updates — pay changes, bulk manager reassignments — were triggering cascades of unnecessary IT notification emails. A single payroll cycle could generate dozens of alerts for changes that required zero IT action. We implemented intelligent change detection that compares incoming HR data against current directory state field-by-field, and only fires notifications when actionable attributes actually change. ### Duplicate Account Creation The original system relied on email address matching to determine if a user already existed. This broke whenever email formats differed between systems. We shifted to using the HR system's unique employee identifier as the canonical match key, with email as a fallback — virtually eliminating duplicate account creation. ### Ghost Processing of Terminated Employees Manager reassignments on terminated employee records were being interpreted as new-hire events, triggering account creation workflows for people who had already left the company. We added early-exit logic that checks employment status before any processing occurs. ### Broken Email Templates IT notification emails had accumulated formatting issues — double-encoded HTML, inconsistent layouts, and missing information. We rebuilt the templates with clean, color-coded designs that surface the right information at a glance. ## Architecture: Bridging Cloud and On-Prem Paylocity HR System Azure Logic Apps Orchestration Layer Cloud Users On-Prem Users Entra ID Cloud Identity Azure Function Bridge Layer On-Prem Active Dir M365 Licensing High-level architecture: Paylocity events flow through Azure Logic Apps, which route to either cloud (Entra ID / Microsoft Graph) or on-premises Active Directory via an Azure Function bridge. The system uses a hybrid routing model. When an HR event comes in, the orchestration layer checks whether the user is cloud-managed or on-premises-synced. Cloud users are updated directly via the Microsoft Graph API. On-prem users are handled through a serverless function that securely bridges into the on-premises domain controller over an encrypted channel. This design means a single webhook from the HR system can drive changes across both identity tiers without any manual IT intervention. ## Two Automation Modes ### Event-Driven (Real-Time) When Paylocity fires a webhook — new hire, role change, termination, or leave of absence — the system processes it in near real-time. It fetches the full employee record, compares it against current directory state, determines the action type, and executes accordingly. Creates and updates go through an approval step; terminations execute immediately per HR policy. ### Scheduled Sync (Nightly) A separate scheduled job sweeps all employees across all company entities twice daily. This catch-all ensures no changes slip through the cracks if a webhook is missed, and keeps attributes like job title and employee ID consistently synchronized. ## Phased Delivery We delivered this project across eight incremental phases, each building on the last. Every phase was designed to be independently deployable with its own rollback plan and verification checklist. This approach let us ship improvements quickly while minimizing risk to a system that touches every employee's account. **Key wins from the phased approach:** - Eliminated notification flooding from pay and bulk manager changes - Resolved duplicate account creation through employee ID-based matching - Added leave of absence handling — automatically disabling and re-enabling accounts - Built a global error handler that alerts admins with diagnostic information when something fails - Backfilled employee IDs for 100+ existing users across both cloud and on-prem directories ## Backfill: Closing the Data Gap The shift to employee ID-based matching only works if existing users actually have that field populated. We built one-time backfill scripts that matched existing directory users to their Paylocity records by email, then wrote the employee ID back to the appropriate system — Graph API for cloud users, the on-prem bridge function for synced users. Over 100 users were backfilled in a single pass. ## Results The system now handles the full employee lifecycle — hire, update, leave, and termination — across a hybrid cloud/on-prem environment with minimal IT involvement. Notification noise has been dramatically reduced, duplicate accounts are a thing of the past, and the phased architecture gives the team a clear path for future enhancements like phone number sync and department-to-office mapping. This project is a good example of how targeted automation layered onto existing infrastructure can deliver outsized value without requiring a wholesale platform migration. --- # How We Made Keyframe Editing Feel Like Moving a Camera > https://www.solvedsystems.com/blog/how-we-made-keyframe-editing-feel-like-moving-a-camera Martin Rodriguez · Engineering · 2026-02-23 We replaced nine property tracks and manual number entry with a visual framing overlay that lets you drag a rectangle on the video preview to control zoom and pan keyframes. We have a keyframe animation system in our video editor. Zoom, pan, rotation, opacity. You place keyframes on a timeline, pick an easing curve, and the engine interpolates between them. Technically it worked fine. In practice, nobody could figure out how to use it. The old interface exposed nine separate property tracks: zoom, rotation, pan X, pan Y, opacity, crop X, crop Y, crop width, crop height. Each with its own draggable diamonds, value sliders, and percentage inputs. If you wanted to do something as simple as "start flat and gradually zoom into this area," you had to coordinate four tracks and eight keyframes, all entered as numbers. > That's not editing. That's data entry. ## What We Changed We added a visual framing overlay, a draggable, resizable rectangle that sits directly on the video preview. Click "Frame" in the canvas toolbar and a sky-blue rectangle appears showing exactly what region the viewer will see. Make the rectangle smaller and the clip zooms in. Drag it around and the clip pans. The math is simple: rectangle width as a percentage of the frame maps to zoom level, rectangle center maps to pan offset. It works like the crop tool we already had. Same dark overlay outside the active region, same rule-of-thirds grid, same corner handles. But instead of cutting pixels away, the framing overlay controls a virtual camera. When you click "Frame," the right panel automatically switches to the Animations tab and scrolls to the keyframe section. You see the connection immediately. The rectangle on the canvas controls the same zoom and pan values that the keyframe tracks display as curves and diamonds. The typical workflow: scrub to 0%, leave the rectangle at full size (1x zoom, centered), click "Set Keyframe." Scrub to 15%, drag the rectangle smaller and position it over the area you want to highlight, click "Set Keyframe" again. Click "Done." Play it back and you get a smooth zoom-in. Pick "Ease In-Out" and it ramps up naturally. The tracks, curves, and sliders are all still there in the Animations panel. You can drag keyframes to adjust timing, tweak values, or change easing. But the starting point is always what you see on the canvas, not what you type into a field. ## Why an Overlay Our first attempt was gesture-based: scroll to zoom, drag to pan. It technically worked, but on trackpads, scroll and pinch overlap with browser and canvas viewport zoom. The gesture was invisible. Nothing on screen told you that scrolling would zoom the clip. And dragging conflicted with canvas pan when the viewport was already zoomed in. The overlay solves all of this. It's a visible affordance. You see the rectangle, you know you can drag and resize it. No gesture ambiguity, no trackpad conflicts. Canvas viewport zoom still works independently because it operates on the outer container, not the overlay. ## Before and After **Before:** Open the zoom track, add a keyframe at 0% with value 1, add another at 50% with value 1.3, repeat for pan X and pan Y. Hope the numbers match what you had in your head. **After:** Click "Frame." Drag the rectangle to frame your starting shot, click "Set Keyframe." Scrub forward, resize and reposition for the ending shot, click "Set Keyframe." Done. The interpolation engine, the easing curves, the SVG curve visualization, none of that changed. We just stopped making people speak the engine's language and let them work with what they could see. --- # How We Replaced Hardcoded Video Templates with AI-Generated Layouts > https://www.solvedsystems.com/blog/replaced-hardcoded-video-templates-ai-generated-layouts Martin Rodriguez · Engineering · 2026-02-19 We had 48 hardcoded Remotion templates that made every client's video look the same. Here's how we replaced them with an AI-driven scene description language that treats layout as data — and never wrote another template again. ## The Template Trap When we first built programmatic video generation into our marketing platform, we did what everyone does: we wrote templates. Four Remotion compositions — Feature Announcement, Product Demo, Social Teaser, Release Notes — each in three durations and four visual styles. That's 48 variants. Every one of them was a monolithic React component with hardcoded layout positions, bespoke animation timing, and pixel-perfect element placement that only worked at one aspect ratio. Adding a new element meant touching every file. Supporting square format for social meant forking everything. Again. The worst part? A fintech startup and a food delivery app got the exact same layout. Different hex colors, same structure. The videos looked generated because they *were*. ## Treating Layout as Data, Not Code We kept running into the same wall: we were encoding design decisions in React components when we should have been encoding them in data. Video layouts are a spatial problem — where does the title go, how do the bullet points reveal, when does the scene crossfade. That's not a code problem. That's a *direction* problem. So we tried something different. Instead of writing more templates, we designed a structured format that could describe any marketing video scene — and handed the actual composition work to an LLM. We'll be honest, we weren't sure this would work. Spatial reasoning felt like a stretch for a language model. But it turns out that if you give the AI tight enough constraints — a fixed vocabulary of element types, bounded numeric ranges, validated fields — it's surprisingly good at arranging things on screen. The trick was never asking it to be creative in an open-ended way. We gave it a box to work in, and it filled the box well. ## The Scene Description Language This was the hard part. Not the AI integration — that was relatively straightforward once the schema existed. Designing a vocabulary that was expressive enough for professional-looking motion graphics but rigid enough to never produce garbage output took us longer than we'd like to admit. We ended up with seven element types: **text**, **badge**, **button**, **list**, **image**, **shape**, and **container**. Each one maps to a specific visual component — badges are pill-shaped labels, containers can render as browser windows or phone mockups or terminals, lists have per-item stagger timing. Everything is positioned with percentages. `{x: 50, y: 40}` means center-horizontal, slightly above middle. We added an anchor point system — nine positions like `center`, `topLeft`, `bottomRight` — so you can say "put the bottom-left corner of this element at coordinates 10, 90" without doing offset math. This sounds like a small thing. It wasn't. Percentage-based positioning is the reason we can render the same scene description at 1920×1080 and 1080×1080 without changing anything. That one decision saved us weeks of work we would have otherwise spent maintaining parallel layouts. Each element gets two animation properties: an **entrance** (how it appears — slide up, spring pop, fade in, typewriter effect) and an optional **continuous animation** (subtle ongoing motion — a floating drift, a pulse, a Ken Burns zoom). The AI picks both per element. We validate the whole thing server-side with a schema before it hits the renderer. If the AI returns something malformed, we catch it there and fall back to a simpler deterministic composition. ## Why Frame-Based Animation Matters Our videos render on AWS Lambda. There's no browser animation runtime there, no `requestAnimationFrame`, no CSS transition engine. Every frame gets rendered independently in parallel across dozens of workers. So every animation has to be a pure function of the frame number — give it frame 247 and it produces the exact same output every time, no matter which Lambda instance runs it. We built a small animation engine on top of Remotion's `interpolate()` and `spring()` primitives. Entrance animations combine opacity, translation, and scale. A five-item list can stagger its reveals 0.2 seconds apart just by incrementing a delay value per item. Continuous animations use sine waves for floating motion, subtle scale oscillation for pulses, and slow pan-and-zoom for Ken Burns effects on images. They're tiny details, but they make the output feel like motion graphics instead of a slideshow. We spent a while trying to get the spring physics right for the "pop" entrance animation — the damping and stiffness values went through maybe twenty iterations before the bounce felt natural without being distracting. That kind of tuning doesn't show up in architecture diagrams but it's where the output quality actually lives. ## Making It Brand-Aware Generic videos with different color swatches was the whole problem we were trying to solve, so brand awareness had to go deeper than palette swapping. When someone generates a video, we pull their full brand context from the database: colors (primary, secondary, accent, plus any extended palette we extracted from their codebase), font names and actual font files, their logo, and what we call **"brand intelligence"** — an elevator pitch, key features, selling points, and tone of voice that we extract automatically from their connected GitHub repository. All of this gets fed to the AI when it composes scenes. It writes real marketing copy for headlines and CTAs based on what the product actually does. It adapts layout density and visual weight to match the brand's personality. A developer tools company gets clean, minimal compositions. A consumer app gets bolder, more energetic layouts. The font loading was a fun challenge. We inject `@font-face` declarations dynamically at render time from remote font file URLs. It means the brand's actual typeface shows up in the video — their heading font on titles, their body font on descriptions. We're consistently surprised by how much this one detail moves the needle on whether output feels "on-brand" or "obviously generated." ## The Full Pipeline The request flow is pretty linear: assemble brand context from the database, feed it to the AI scene generator, validate the returned JSON against our schema, pick the right Remotion composition for the duration and aspect ratio, ship it to Lambda for parallel rendering, then poll until it's done and store the result. A 30-second video renders in under a minute. Lambda parallelizes across frame chunks, so render time scales with compute rather than video length. The fallback system deserves a mention because it's boring and that's the point. If the AI call fails for any reason — timeout, bad output, rate limit — we generate deterministic scenes that still use the brand's real colors, name, and description. They're simpler layouts, but they're never broken. In practice the fallback fires on a small percentage of requests. But it means our effective render success rate is 100%, and we sleep better knowing that nobody's brand is getting a white screen. ## What We'd Tell Our Past Selves Designing the constraint schema was more important than any prompt engineering we did. The schema is what makes the output reliable — not clever instructions, not few-shot examples, not temperature tuning. The AI can't place text at -500% or set a font size to zero because the schema literally won't accept it. We wish we'd internalized that earlier instead of spending time on prompt iteration. Commit to percentages for positioning from day one. We briefly considered pixel-based coordinates and we're glad we didn't go down that road. Every time we add a new aspect ratio, it just works. No layout code changes. The fallback system was one of those things that felt like over-engineering when we built it. It's not. When you're generating content that represents someone's brand, you can't ship failures. The boring reliability code is what makes the flashy AI code viable in production. And the best signal that the architecture is right: every major feature we've added since — voiceover support, logo placement, brand font loading — plugged in without rethinking anything. Voiceover was adding an audio component. Logos were a new image source type. Fonts were a loader function. We haven't written a new template in months, and we don't think we ever will again. --- # How We Cut Token Consumption by 98% Moving from Tool Calling to Code Execution > https://www.solvedsystems.com/blog/cut-token-consumption-98-percent-tool-calling-to-code-execution Jeff Bernard · Engineering · 2026-02-11 Every MCP tool call was flooding our context window with raw JSON. By shifting to server-side code execution, we reduced token consumption by 95-99% across our energy industry API integrations. ## The Problem: Death by Documentation If you're building AI agents that talk to APIs, you've probably run into the same wall we did: token bloat. Every tool call returns massive JSON payloads that flood your context window, burn through your budget, and slow everything down. We fixed it by fundamentally rethinking how our MCP server handles API interactions — shifting from traditional tool calling to server-side code execution. The results were dramatic. PatchOps is our unified MCP server that gives AI agents access to energy industry APIs — Corva for drilling operations, Enverus for market intelligence, WellDatabase for well data, GeoForce for device tracking, and Microsoft 365 tools like Outlook, Teams, and Planner. In the original architecture, every MCP tool call followed the standard pattern: Claude sends a request, the server calls the API, and the full response gets stuffed back into the context window. Simple enough. Except it was hemorrhaging tokens. The worst offender? Every single PatchOps response included an "LLM Connector Guide" — documentation for *all* connectors — regardless of which API you were actually querying. Ask for one Outlook email? Here's 8,000+ tokens of documentation for WellDatabase, GeoForce, Corva, Enverus, and Snowflake too. **Wake-up call:** In one real conversation, retrieving a few emails consumed 68,000 tokens. Only about 2,000 of those were actual useful data. That's a 2.9% signal-to-noise ratio. A single GeoForce query returning 118 devices would dump ~47KB of raw JSON into the context — roughly 12,000 tokens of coordinates, battery statuses, timestamps, and metadata that Claude then had to parse through just to answer "how many active devices do I have?" ## The Fix: Let the Server Do the Work Instead of returning raw API responses for Claude to digest, we moved to a code execution model. Claude writes a small JavaScript snippet describing what it wants, the PatchOps server executes it against the API, and only the processed result comes back. BEFORE — Tool Calling Claude PatchOps MCP GeoForce API 47KB Raw JSON ~12,000 tokens AFTER — Code Execution Claude code snippet PatchOps executes server-side fetch → filter → aggregate 464 bytes ~150 tokens 98.75% reduction Before: raw API payloads flood the context. After: server-side execution returns only the answer. Before: ``` Claude → "list all GeoForce devices" → PatchOps → GeoForce API → 47KB raw JSON → Claude context Result: ~12,000 tokens consumed ``` After: ``` const devices = await geoforce.listDevices(); return { total: devices.length, active: devices.filter(d => d.state === 'ACTIVE').length }; // Result: ~150 tokens consumed ``` The AI generates targeted code that fetches, filters, and aggregates on the server side. Only the answer comes back — not the raw material. ## The Numbers We ran extensive benchmarks comparing both approaches across real workloads. **98.75%** GeoForce reduction **97.5%** Outlook reduction **39x** Efficiency gain **$512/yr** Cost savings (50 users) ### Token Reduction by Scenario ScenarioTool CallingCode ExecutionReduction GeoForce: 118 devices12,000 tokens150 tokens**98.75%** Outlook: Email retrieval68,000 tokens1,726 tokens**97.5%** Corva: Rig list8,000 tokens1,107 tokens**86%** Enverus: Basin query~8,000 tokens1,361 tokens**83%** Multi-API dashboard24,000 tokens300 tokens**98.75%** The GeoForce case is the clearest illustration. A query that previously returned 47KB of device telemetry now returns a 464-byte summary. That's a **100x reduction** in context size. For the Outlook case, the improvement was even more striking in absolute terms. We went from 68,000 tokens — where 48,000 were wasted on connector documentation repeated six times — down to 1,726 tokens of actual email content. A **39x improvement** in efficiency. ### Cost Impact At Claude API pricing ($0.80/1M input tokens), the per-call savings look small but scale fast: - **Per call:** $0.0096 → $0.00012 (99% reduction) - **Monthly (30 calls/user):** $0.288 → $0.0036 - **Annual across 3 APIs, 50 users:** ~$512/year saved These numbers get more interesting when you factor in that the reduced context also means faster responses and fewer cases where conversations hit context limits — which means fewer retries and restarts. ### Speed Tradeoff There is one tradeoff: latency. Direct tool calls return in ~100-120ms. Code execution takes 6-7 seconds because it includes runtime boot, API call, and server-side processing. MethodLatencyTokensBest For Direct tool call~120ms12,000Single lookups, real-time dashboards Code execution~6,000ms150Bulk operations, analytics, reports For a single device lookup where a user is waiting, 120ms wins. For pulling a fleet summary, generating a report, or orchestrating across multiple APIs, the 6-second wait is negligible compared to the 98% token savings. ## The Hybrid Approach We didn't go all-in on either method. PatchOps now uses a hybrid strategy: **Code execution** for bulk data, aggregations, multi-API orchestration, filtering, and any operation where you don't need every field from every record. This is the default path for analytics-style queries. **Direct tool calling** for single-item lookups, time-critical operations, and cases where complete raw data is needed for downstream processing. **Routing heuristic:** If the query smells like "get me this specific thing," use a direct call. If it smells like "tell me about all the things," use code execution. ## What Actually Changed Architecturally The shift required three things: 1. **Wrapping each API connector as an executable context.** Each connector (Corva, Enverus, GeoForce, Outlook, etc.) is available as a pre-authenticated client inside the code execution sandbox. Claude doesn't need to know about auth tokens, endpoints, or pagination — it just calls `await corva.getRigs()`. 2. **Eliminating the connector guide from responses.** The biggest single win was removing the 8,000-token documentation payload that shipped with every response. Connector method signatures are now discovered through a lightweight `getConnectorDocs` call (~50 tokens) that only returns the relevant connector. 3. **Server-side JavaScript execution via Azure Functions.** The code runs in a sandboxed runtime with access to pre-configured API clients. Boot time is ~5ms, runtime initialization ~150ms, and the actual API call typically ~90ms. The bulk of the 6-second latency is data processing for large result sets. ## Lessons Learned **Token cost is the real bottleneck, not latency.** We initially worried about the 6-second execution time. In practice, nobody cares about 6 seconds when they're asking for a fleet summary or generating a report. But everyone cares when their conversation hits the context limit halfway through a workflow because earlier API calls ate 68,000 tokens returning documentation nobody asked for. **The 35ms MCP protocol overhead is irrelevant.** We spent time benchmarking whether calling functions directly vs. through MCP tool protocol made a difference. It's 35ms. Not worth optimizing when your real savings are in the 98% token reduction column. **Useful data ratio matters more than total token count.** The Outlook conversation was the wake-up call. 68,000 tokens consumed, 2,000 tokens of useful data. That's a 2.9% efficiency rate. After code execution, we're consistently above 90% useful data in every response. **Let the server aggregate.** The instinct with LLM tool use is to bring data to the model and let it reason over raw information. For structured API data, that's backwards. The server can filter, count, and summarize far more efficiently than burning tokens to have the model parse JSON. ## Bottom Line Moving from traditional MCP tool calling to server-side code execution gave us a **95-99% reduction in token consumption** across our energy industry API integrations. The architecture is simple: pre-authenticated API clients in a sandboxed runtime, lightweight method discovery, and letting Claude write targeted extraction code instead of drowning in raw payloads. If you're building MCP servers that wrap data-heavy APIs, the code execution pattern is worth serious consideration. The token savings alone justify the architectural shift — and your users will thank you when their conversations stop hitting context limits mid-workflow. --- # How We Automated 200+ Daily Tasks for an Oil & Gas Company > https://www.solvedsystems.com/blog/automated-200-tasks-oil-gas Jeff Bernard · Case Studies · 2025-01-15 From 40+ manual spreadsheets to intelligent automation. A case study in systematic workflow transformation. ## The Problem A mid-size oil and gas company managed daily operations across 40+ spreadsheets. Data entry consumed 15+ hours weekly. Critical information was scattered, making strategic decisions slow and error-prone. Their operations team spent mornings copying data between Excel files, manually updating production logs, and reconciling discrepancies across systems. By the time reports reached leadership, the data was already outdated. The company knew they needed automation. But they didn't know where to start. ## Our Approach We built an AI-powered workflow system that automatically collects, processes, and routes operational data. Smart automations handle 200+ daily tasks that previously required manual input. ### Phase 1: Core Infrastructure (Weeks 1-3) We started with the highest-impact bottleneck: field data collection. Using Azure Logic Apps and Power Automate, we connected their production monitoring systems directly to their central database. Field updates now sync in real-time. No manual entry. No delays. No errors. ### Phase 2: Integration Layer (Weeks 4-6) Next, we connected their six disconnected systems: - Production monitoring → Database - Database → Paylocity (HR/payroll) - Database → QuickBooks (accounting) - Database → Power BI (reporting) - Field sensors → Alert system - Compliance logs → Automated reporting Every system now talks to every other system. Data flows automatically. ### Phase 3: Intelligence Layer (Weeks 7-8) The final phase added AI decision-making. Custom workflows now: - Route information based on production thresholds - Flag anomalies before they become problems - Generate compliance reports automatically - Send proactive alerts to the right team members The system doesn't just move data—it makes decisions. ## Results ### Time Saved - 15+ hours per week previously spent on manual data entry - 3-4 hour reporting delay eliminated entirely - 200+ daily tasks now handled automatically ### Operational Impact - Real-time visibility into production metrics - Faster decision-making with live dashboards - Proactive issue detection before problems escalate - Compliance reporting reduced from 2 days to 2 hours ## Key Takeaways 1. **Start with the highest-impact bottleneck** - Don't try to automate everything at once. Find the one workflow that's costing you the most time. Automate that first. 2. **Your existing logic probably works** - Most businesses don't need to reinvent their processes. They just need to make them automatic. 3. **Integration is infrastructure** - The real value isn't in individual automations. It's in connecting your systems so data flows automatically. 4. **Custom doesn't mean expensive** - We built enterprise-grade automation using Microsoft's cloud stack and smart integrations. No proprietary software. No vendor lock-in. 5. **Automation compounds** - Every automated workflow feeds better data to other workflows. The system gets smarter over time. ## Ready to Eliminate Manual Work? We don't just consult. We build, implement, and maintain intelligent systems that eliminate manual work and give you space to focus on growth. Schedule a free consultation. We'll audit your workflows, identify automation opportunities, and show you exactly what's possible for your business. --- # Upstream Production Workflow Automation > https://www.solvedsystems.com/projects/upstream-production-workflow-automation Industry: OIL & GAS OPERATIONS Mid-size operator managing daily operations across 40+ spreadsheets. We built an AI-powered workflow system that automatically collects, processes, and routes operational data. - **15+** hours saved weekly - **200+** tasks automated daily - **Real-time** visibility ## The Challenge A mid-size oil and gas operator was managing daily upstream production operations across more than 40 separate spreadsheets. Field data from well tests, production reports, and maintenance logs were manually entered, copy-pasted between files, and emailed to supervisors for review. Errors were frequent, reports were delayed, and critical decisions were made on stale data. The operations team spent 15+ hours per week just collecting and consolidating information—time that should have been spent optimizing production and managing assets. ## Our Approach We designed an AI-powered workflow system that replaced the manual spreadsheet process entirely. The solution was built in three phases: - **Data Collection Layer:** Automated ingestion from field sensors, SCADA systems, and manual entry forms into a unified data pipeline. No more copy-pasting between spreadsheets. - **Processing & Validation:** AI models validate incoming data against historical patterns, flagging anomalies and auto-correcting known formatting issues before they reach decision-makers. - **Routing & Reporting:** Processed data is automatically routed to the right teams with role-based dashboards. Production engineers see production data. Maintenance teams see maintenance alerts. Executives see rollups. ## The Technology The system integrates with existing SCADA infrastructure and ERP systems via secure API connections. Data processing runs on Azure cloud infrastructure with real-time event-driven architecture. Custom AI models handle data validation and anomaly detection, trained on 18 months of historical operational data. ## Results Within the first month of deployment, the operator saw transformational improvements across their daily operations: - **15+ hours saved weekly** — Operations staff redirected from data entry to actual operations management - **200+ tasks automated daily** — From data collection to report generation, manual touchpoints were eliminated - **Real-time visibility** — Executives and field managers now see the same live data, eliminating reporting delays - **98% data accuracy** — AI validation caught and corrected errors that previously went unnoticed for days ## What This Means This engagement demonstrated that mid-size operators don't need enterprise-scale digital transformation budgets to modernize their operations. Targeted automation of high-friction workflows delivers immediate, measurable ROI without disrupting existing infrastructure or requiring extensive retraining. --- # Inventory Management System Integration > https://www.solvedsystems.com/projects/inventory-management-system-integration Industry: MANUFACTURING Connected legacy ERP system with modern AI analytics platform, eliminating manual data entry and creating real-time inventory visibility. - **3** systems unified - **89%** less data entry - **Same-day** accuracy ## The Challenge A regional manufacturing company was running three separate systems for inventory management: a legacy ERP system from the early 2010s, a warehouse management tool, and a procurement spreadsheet maintained by the purchasing team. None of these systems talked to each other. The result was a daily ritual of manual data reconciliation. Warehouse staff would count inventory, enter it into the WMS, then email updates to the procurement team, who would manually update their spreadsheet and cross-reference with the ERP. Discrepancies were discovered days—sometimes weeks—after they occurred. ## Our Approach Rather than ripping out and replacing the legacy systems (which would have been prohibitively expensive and disruptive), we built an integration layer that connected all three systems into a single source of truth: - **API Bridge:** Custom middleware that translates data between the legacy ERP's proprietary format, the WMS REST API, and the procurement team's structured data needs. - **Real-Time Sync:** Event-driven architecture ensures that when inventory changes in any system, all other systems reflect the update within minutes. - **AI Reconciliation:** Machine learning models continuously compare data across systems, automatically resolving minor discrepancies and flagging significant ones for human review. ## The Technology The integration layer runs on Azure Functions with event-driven triggers. We used a message queue architecture to handle the different update frequencies of each system. The AI reconciliation engine was trained on 12 months of historical discrepancy data to learn common error patterns. ## Results - **3 systems unified** — Legacy ERP, WMS, and procurement now share a single source of truth - **89% less manual data entry** — Staff time redirected from data entry to exception handling and strategic procurement - **Same-day accuracy** — Inventory counts now reconcile within hours instead of weeks - **$180K annual savings** — Reduced carrying costs from overstock situations caused by data lag ## What This Means Legacy systems don't have to be a barrier to modernization. With the right integration approach, businesses can preserve their existing technology investments while gaining the real-time visibility and automation capabilities they need to compete. --- # Document Processing Automation > https://www.solvedsystems.com/projects/document-processing-automation Industry: FINANCIAL SERVICES AI-powered invoice and contract processing system that handles document intake, data extraction, and routing—eliminating 72-hour turnaround times. - **500+** docs/month - **94%** accuracy rate - **72hr** delays eliminated ## The Challenge A financial services firm processed over 500 invoices and contracts per month. Each document arrived via email, was manually reviewed by a team member, had key data points extracted and entered into their accounting system, then was routed to the appropriate approver. The entire process took an average of 72 hours per document. During peak periods, the backlog grew to over a week. Late payments incurred penalties. Contracts sat unsigned. And the processing team was stretched thin, leading to extraction errors that created downstream accounting issues. ## Our Approach We built an end-to-end document processing pipeline that handles the entire workflow from intake to approval: - **Intelligent Intake:** Documents arriving via email are automatically classified (invoice, contract, purchase order, etc.) and queued for processing. No manual sorting required. - **AI Data Extraction:** Custom-trained models extract key fields—vendor name, amounts, dates, line items, contract terms—with 94% accuracy on first pass. - **Smart Routing:** Based on document type, amount, and vendor, documents are automatically routed to the correct approver with pre-populated approval forms. - **Exception Handling:** Low-confidence extractions are flagged for human review with the AI's best guess pre-filled, turning a 10-minute manual task into a 30-second verification. ## The Technology The system uses Azure AI Document Intelligence for OCR and field extraction, with custom fine-tuned models for the client's specific document formats. The workflow engine runs on Azure Logic Apps with custom connectors to their accounting platform. All data is encrypted in transit and at rest. ## Results - **500+ documents processed monthly** — With no increase in staff - **94% extraction accuracy** — On first pass, with human review catching the remaining 6% - **72-hour delays eliminated** — Average processing time dropped from 3 days to under 4 hours - **Zero late payment penalties** — Since deployment, the firm has not incurred a single late payment fee ## What This Means Document processing is one of the highest-ROI automation opportunities in financial services. The combination of AI extraction and intelligent routing transforms a labor-intensive bottleneck into a streamlined, near-real-time process. --- # Customer Onboarding Automation > https://www.solvedsystems.com/projects/customer-onboarding-automation Industry: SAAS OPERATIONS Built intelligent onboarding workflow that automatically provisions accounts, sends documentation, and tracks completion—scaling from 10 to 100+ customers monthly. - **10x** capacity increases - **Zero** new headcount - **2 hours** vs 5 days ## The Challenge A growing SaaS company was onboarding roughly 10 new customers per month with a fully manual process. Each new customer required account provisioning across three platforms, welcome email sequences, documentation delivery, training scheduling, and completion tracking. The customer success team managed it all through a shared spreadsheet and calendar. As the company's sales pipeline grew, the onboarding process became the bottleneck. New customers waited up to 5 business days to get fully set up. The success team was spending 80% of their time on repetitive setup tasks instead of building customer relationships. ## Our Approach We designed an intelligent onboarding system that automates the entire customer setup workflow: - **Automated Provisioning:** When a deal closes in the CRM, the system automatically creates accounts across all required platforms, configures permissions, and generates API keys. - **Dynamic Documentation:** Customized onboarding documentation is automatically generated based on the customer's plan tier, industry, and specific use cases. - **Progress Tracking:** A real-time dashboard shows onboarding status for every customer, with automated nudges when steps are overdue. - **Smart Escalation:** If a customer hasn't completed key onboarding steps within defined timeframes, the system escalates to the success team with full context. ## The Technology The onboarding engine integrates with HubSpot CRM, the client's SaaS platform APIs, and Microsoft 365 for documentation and communication. Workflow orchestration runs on a serverless architecture with event-driven triggers. Custom templates handle documentation generation with dynamic content insertion. ## Results - **10x capacity increase** — From 10 to 100+ customer onboardings per month without process degradation - **Zero new headcount** — Existing success team handles 10x volume by focusing on high-value interactions - **2 hours vs 5 days** — Customer setup time dropped from 5 business days to under 2 hours - **92% onboarding completion rate** — Up from 64%, driven by automated progress tracking and nudges ## What This Means Customer onboarding is often the first experience a new customer has with your company after signing. Automating the mechanical parts of onboarding frees your success team to focus on building relationships and driving adoption—the work that actually reduces churn and increases expansion revenue. --- Machine-readable index: https://www.solvedsystems.com/llms.txt · Sitemap: https://www.solvedsystems.com/sitemap.xml Contact: info@solvedsystems.com · https://www.solvedsystems.com/contact