Secure AI Agent for Enterprise Data Access | MEV AI Development

Services

Product Engineering<br>Software Product DevelopmentModernization & Legacy Repair<br>AI Engineering<br>AI Development ServicesАgentic AI Orchestration<br>Run & Operate<br>Application Maintenance & SupportDevOps & Cloud Operations<br>Audit & Due Diligence<br>M&A Technical Due DiligencePre-Deal Software AuditSoftware Health Check

Discover All

Industries

Life ScienceHealthcareHealthcare Data Management<br>Real EstateMedia and EntertainmentProgrammatic Advertising

Portfolio

About Us

BlogCareer

Contact Us

Back to Blog

May 15, 2026

Designing a AI Access Layer for Systems of Record: A Case Study in Team Capacity Planning

...

...

Share:

There’s no need to guess — you’re definitely using systems of record: ERPs, financial systems, capacity planners, CRMs, HRIS, ITSM tools. For us at MEV, those systems hold the answers: who is available when, who owns which account, where a ticket is stuck, and who will be on the bench next month. The issue is the cost of access: every question turns into several screens, filters, and a context switch, which breaks the flow of a call.<br>We ran into this problem ourselves long before we started thinking about an AI agent. Inside MEV, we use an internal custom-built system called TeamPlanner for capacity planning and staffing visibility. TeamPlanner tracks people, projects, assignments, time off, departments, levels, locations, and related attributes. The data model can already answer most staffing questions. It has the data we need, and it does the job. But in practice, getting a simple answer still meant opening the app, setting filters, and pulling the pieces together by hand.<br>With AI becoming part of everyday work, those extra steps stood out as friction points. We wanted a simpler way to get answers from the system without making people dig for them every time.

Power Your Business With Artificial Intelligence

Talk to an Expert →

This case is about the first stage of the journey: the groundwork that made it possible to build an AI agent over TeamPlanner that is read-only, respects existing authentication and authorization, and treats TeamPlanner as the single source of truth instead of creating a parallel data store.<br>Initial Issue: data is there, access cost is too high<br>On the data side, TeamPlanner already answers questions like:<br>“Who’s an engineer/analyst/manager on project X?”<br>“What does the engineering bench look like in February and March?”<br>“What’s the allocation summary for project X (2×senior engineers, 1×manager, …)?”<br>The model and API cover people, roles, levels, departments, projects, assignments, and time off.

Custom-Built System for Capacity Planning and Staffing VisibilityThe problem is how you reach those answers. Each question usually means:<br>opening TeamPlanner;<br>finding the right project;<br>switching tabs;<br>adding filters;<br>checking multiple screens;<br>sometimes exporting data and doing the last steps mentally.<br>That effort is fine if you do it once in the morning. It fails in the middle of a staffing call where you have 30–60 seconds before the discussion moves on.<br>Business requirement: keep the same answers and the same source of truth, but expose them through a chat interface (Claude, ChatGPT, etc.) with latency that fits into a live conversation. If an “AI agent” also needs 5–10 minutes of manual steering per question, it turns into a worse UI, not an access layer.<br>V1 scope: narrow & read-only<br>For the first version we kept the scope deliberately small. The agent just acts as an access layer.<br>What V1 must do<br>V1 AI agent covers a narrow class of questions:<br>who / what / when about people, projects, assignments, bench, and availability over a period;<br>all answers derived only from TeamPlanner as the system of record;<br>every call goes through the TeamPlanner API and respects per-user permissions enforced there.<br>If a user cannot see something in the UI, the agent must not be able to show it.<br>V1 guardrails (one set of constraints)<br>These guardrails apply everywhere in the design:<br>Read-only – the agent can observe and analyze, but it cannot write, trigger side effects, or change system state. Later versions may expand this boundary and allow controlled agent-initiated changes where appropriate.<br>API-only data access – all data goes through the TeamPlanner API; no direct DB access, no raw SQL.<br>No extra infra in the proxy – no cache, no ETL, no background jobs, no queues inside the MCP server.<br>No embedded model calls – the MCP server never calls LLM providers; models live in clients.<br>Limited surfaces in V1 – direct MCP-capable clients only; Slack and other chat surfaces are handled separately.<br>V1 lowers access cost to existing data without extending authority or surface area. Later sections refer back to these guardrails instead of repeating them.<br>Architecture in one picture<br>At runtime the AI access layer is a small proxy that forwards a fixed set of tool calls to the existing TeamPlanner API. It does not own business...