One AI platform, four products, one set of rules
Lead architect of the shared platform behind four AI product capabilities, from model access to agent actions.
- Amazon Bedrock
- Aurora PostgreSQL
- pgvector
- EKS
Services
An AI agent that can change business data needs an action layer with rules. I design that layer around a single MCP action server: versioned tool manifests, human approval on every write, idempotent execution, a replayable decision log and an identity that never exceeds the user’s rights.
Reading is low risk and writing is not. If an agent calls business APIs directly, each integration decides on its own what the agent may do, how it is authorised and what gets logged, and nobody can review the behaviour in one place.
A governed action layer puts those decisions in one service. The agent proposes an action, the layer runs checks, a person approves the concrete parameters, and only then does the action execute. Every step is written to a log that can be replayed and explained afterwards.
An agent calls the single MCP action server, which exposes versioned tool manifests. Each action passes precondition and idempotency checks and, for every write, human validation. Only then is the action executed. An append-only decision log makes every AI decision replayable, with a WORM export to S3 Object Lock. Throughout, the agent inherits the requesting user permissions through OAuth2 Token Exchange and never exceeds them.
All agent actions go through a single Model Context Protocol server, which holds the downstream credentials and decides whether a call may proceed.
Each tool declares its purpose, schemas, whether it reads or writes and which checks apply, and agents and evaluations pin to a version.
Every write needs approval of the exact parameters. Idempotency keys and precondition checks make a retried or stale action safe.
An append-only log of proposals, approvals, rejections and executions, exported to write-once storage such as S3 Object Lock in compliance mode.
OAuth2 Token Exchange so that the agent acts with the requesting user’s permissions and never with more.
How it works
Four steps, each with something you can hold in your hands.
A 30-minute call. You describe what you are building and what is blocking it. I tell you honestly whether I can help.
I review what exists and design the target: a reference architecture and decision records that your team can challenge.
I work inside your team on the hard parts: the gateway, retrieval, agent actions, the pipelines. You get code, not slides.
Evaluation gates, runbooks and dashboards, so your team can run the platform and change it without me.
Lead architect of the shared platform behind four AI product capabilities, from model access to agent actions.
A design guide to governed agent actions over MCP: versioned tool manifests, human validation on writes, idempotency, decision logs and OAuth2 Token Exchange.
A reference architecture for an enterprise AI platform: AI gateway, retrieval, agent actions, evaluation and identity, and the order to build them in.
The Model Context Protocol (MCP) is an open protocol for exposing tools to AI models. Serving all agent actions through one MCP server gives agents a uniform interface and gives the organisation one place to add controls.
Every write does. Reads run without approval. Approval can be relaxed later for specific low-risk tools when their manifest says so; it is a deliberate choice rather than a default.
By logging each proposal, approval, rejection and execution with the tool manifest version, the inputs and the checks that ran, in an append-only log that is exported to write-once storage.
The platform exchanges the user’s token for a scoped token for each downstream call (OAuth2 Token Exchange), so the downstream system sees and enforces the user’s own rights.
Last updated:
Tell me what your agent has to do. After one call you will know whether I can help and what I would design first.
+33 6 02 73 49 22 me@osmanrami.fr