Abstract
Both my technical and sociotechnical projects sit at the juxtaposition where AI is being
integrated into everyday software, and both address the same engineering question of which
safeguards become required and which are left as optional. Approximately 2.86 million customer
service workers in the United States are significantly at risk to AI automation. Every AI product
in this industry drives that exposure through engineering decisions. The major difference
between my projects is the scope of authority at which these decisions are made.
The technical project that I worked on during my capstone SousChef, is a gamified
cooking education platform for beginner chefs learning to expand their culinary abilities through
AI. This project resulted from findings that college students consistently report a
disproportionately lower ability to cook for themselves than older age groups, correlating with
food insecurity and negative health outcomes from consumption of processed meals. The gap
with existing tools for cooking is that they focus on discovering recipes rather than walking
individuals through how to complete each step with visuals and scaffolded practice. SousChef
addresses this through a learning roadmap where dishes progressively get more difficult, and
new skills are introduced to be mastered for later recipes. In the application layer, my team made
scope of authority decisions. We gave access control to user data only in the context of per-user
isolation and restricted AI from accessing non-negotiable materials. The application runs on a
React Native frontend, a Node/Express API, and Supabase Postgres database with Row Level
Security which enforces per-user isolation. The AI SousChef agent which aids users through
suggesting ingredient substitutions and tutorial searches is also gated behind an elevated-user tier
that is only accessible through an admin panel for promotion. In addition to this, rate limiting,
reCAPTCHA, and a series of backend session validations protect sensitive routes from exposure
on the public internet. This prototype established that tightly-scoped AI access is achievable at
the smallest team levels without sacrificing functionality.
In my STS research, I argue that MCP’s specification treats many worker safeguards as
optional rather than required. Overlooked safeguards include human override, UI transparency,
confirmation prompts, and logging, which are all classified in the SHOULD category of MCP’s
founding RFC 2119 language. The major issue is that should an AI agent act erroneously, the
ability to contest this decision is absent from the specifications. The resulting vacuum of
responsibility does not stay empty. Elish’s concept of the moral crumple zone fills the gap. The
nearest human, typically the customer service worker, is assigned accountability for a decision
they never made. This dilemma is not locked to small projects, the scale is visible in industry
leaders like Salesforce. Agentforce autonomously resolves 85% of customer queries, with the
handoff rate dropping from 26% at launch to 5% at last release. The remaining workers in the
crumple zone absorb what the protocol leaves unassigned. The findings point to the need for an
intervention where these features are reclassified from SHOULD to MUST and contestability is
added as a SHOULD. However, with Anthropic’s December 2025 donation of MCP to the Linux
Foundation's Agentic AI Foundation, these defaults are at elevated risk of being ingrained into
the infrastructure of the future’s internet, where even Anthropic’s decision making power is
limited.
The two projects examine the same engineering question at different scales of authority.
Inside SousChef’s application layer, access control and rate-limiting were non-negotiable
requirements for user safety. At the protocol layer, those same decisions would be classified with
a SHOULD label. Companies like Block have shown through their enterprise deployment that
under time pressure these requirements get skipped. Bowker and Star’s concept of infrastructure
inversion showcases why the SHOULD/MUST distinction must be a governance choice rather
than optional housekeeping. Ananny and Crawford’s accountability criteria provides a
benchmark for whether workers can genuinely contest outcomes. Functional AI integration is not
ethical AI integration. Every SHOULD decision shipped in a protocol decides who gets blamed
when something goes wrong, and the protocol designers do not get to pretend otherwise.