Agent and automation platform

An agent can suggest the right action using the wrong source, reuse approval after changing a proposal or resume an execution twice.

• Better prompts alone do not solve those problems.
• I led the design and implementation of controls so the runtime could establish who is requesting an operation, which capability is authorized, where information comes from and what has actually been approved.

The unit of work is an execution with state rather than an unbounded conversation.

This separates interpretation, proposal, approval and effect, preserving a comprehensible path when an external dependency fails.

This case does not provide a public demonstration of agents connected to real services.

• It describes implemented architecture and behaviors exercised in local tests with simulated providers and stores.
• The diagram organizes the path from proposal to authorization, approval and resumption.
• The purpose is to make each boundary available for technical discussion before choosing the integrations a new product requires.

I led the work end to end: translating risks into explicit rules, implementing components and verifying positive and negative scenarios.

Public names, sources and examples have been generalized to preserve confidentiality without removing the engineering decisions that make the case useful.

The runtime uses TypeScript and closed states to represent an agent lifecycle.

• Trusted context is composed on the server.
• Values received from an interface or model response cannot freely select the organization, credentials or available capabilities.
• In the product architecture, Next.js, Supabase and PostgreSQL support interfaces and persistence; the validation slice should not be mistaken for integrated certification of those services.

Explicit states distinguish an execution waiting for approval from an invalid proposal or an operation that can proceed.

They also make it possible to test transitions that must not occur, rather than inferring validity from a generated response.

Source binding associates a source with an organization and the required capability.

• The server checks that relationship before reading.
• An absent, revoked or ambiguous binding is not an invitation to select another source automatically.
• The runtime denies execution when the necessary authorization cannot be established.

This prevents integration convenience from overriding isolation.

• A technically valid credential does not prove that it may be used in the current context.
• The same principle applies to connector responses: origin and scope must remain verifiable throughout the information path, including pagination and subsequent continuation requests.

Human approval is associated with the organization, proposal version and fingerprint.

• If the proposal changes after review, previous approval does not automatically authorize the new action.
• Approval from another context must be rejected.
• The approval button represents a specific authorization rather than blanket consent for any future behavior generated by the agent.

I organized this boundary so the system can explain a refusal.

• This reduces operational ambiguity and supports review: which proposal was shown, which version was authorized and which preconditions are still needed before execution can continue.
• The authorization is represented by system state rather than by wording in a conversation.

The audited MCP implementation is a client that negotiates the protocol and reads resources, including resources/list.

• I do not describe it as a complete tool server or universal support for agent protocols.
• Negotiated capability must match the requested operation; protocol mismatch and unavailable resources are explicit error conditions.

External reads have timeouts, bounded retries, controlled pagination and a circuit breaker.

• A cursor pointing to another domain is rejected, and authorization failures do not trigger indiscriminate retries.
• These controls treat connectors as trust boundaries rather than assuming every call will return valid, correctly scoped information.

Resumption uses a claim and records completion before reporting success.

• This is intended to prevent concurrent attempts from both treating themselves as the owner of the same continuation.
• Persisted state also distinguishes a completed operation from an interrupted response.
• A positive result must correspond to the completion record that supports it.

The tested concurrency slice used an in-memory store.

• That validates the logic under those conditions; it does not replace real database tests, transaction-isolation checks or recovery after an infrastructure failure.
• The distinction matters when deciding what evidence is required before a particular product can be operated.

In the October 4, 2026 audit, 33 agent and isolation tests passed, alongside 8 protocol and readiness tests.

• Negative scenarios include approval from another organization, changed proposals, insufficient capability and absent, revoked or ambiguous sources.
• Tests also exercised external cursors, a 401 response without retry and incompatible MCP negotiation.

These 41 tests establish local behavior for the exercised slice with simulations.

• They do not prove activated external integrations, SQL policies exercised against a real database or full production operation.
• In a hiring discussion, I can explain why each negative scenario exists and which risk it constrains.

I preferred denying an ambiguous source over implicit resolution, and proposal-bound approval over open-ended permission.

• This requires more initial definition but makes execution verifiable.
• I chose explicit states over inferring success from a text response.
• Providers and protocols remain replaceable so runtime behavior can be examined separately from integration failures.

Next steps would depend on the product: certify real persistence, exercise external transports and establish proposal-quality evaluations.

• I do not claim particular multi-agent frameworks or completion of those steps.
• The demonstrated capability is designing autonomy with authorization, continuity and clear operational boundaries, then validating the behaviors that make those boundaries meaningful.

A separate development line contains Python evidence-integrity and OTLP sanitization components: 12 forensic-core tests and 18 privacy tests passed locally.

Complete product integration and runtime activation are not proven.

Next.js, React, Supabase, PostgreSQL, RLS migrations and Docker Compose definitions are present in source.

• They are not presented as operational certification.
• The sanitized report distinguishes the 41 runtime and protocol tests from the 30 observability tests.