Agents for Humans: Shipping TenderLoop on AgentCore with Keyless Vercel OIDC

A polished agent demo becomes much more credible when its production path is real, observable, and deliberately constrained. For the Agents for Humans Hackathon, we took TenderLoop’s Student Coach from a locally verified Strands flow to a live Amazon Bedrock AgentCore Runtime—and kept the model’s authority narrow throughout the move.

TenderLoop helps a student turn an assignment into a manageable study plan, approve exactly what can be shared, and coordinate with parents or temporary caregivers without exposing private conversations. The deployment goal was therefore not simply “put an agent in the cloud.” It was to preserve that privacy boundary after deployment.

## What is live now

The production flow is:

1. The TenderLoop web application sends a validated planning request from its server-side route.
2. Vercel exchanges its production OIDC identity for short-lived AWS credentials.
3. A least-privilege invocation role calls the TenderLoop AgentCore Runtime in Mumbai.
4. The runtime executes the TypeScript Strands agent.
5. Strands uses Amazon Nova Lite through the APAC Bedrock inference profile.
6. The agent must call one typed tool—build_study_plan—and return schema-valid structured output.
7. The interface labels the successful result as Strands · AgentCore.

No long-lived AWS access key is stored in Vercel. The temporary credential used during deployment was revoked after the OIDC path was verified.

## Why the agent is deliberately bounded

The Student Coach is not a general chatbot. Its contract accepts three synthetic inputs: an assignment, a difficulty choice, and a pacing preference. It has a three-turn budget, a student-safety system prompt, and one validated tool.

That tool creates a small plan. It cannot message a parent, grant caregiver access, change policy, or read a private student transcript. Any cross-role action still requires an explicit, previewed object such as a Help Card and an affirmative student approval.

This separation matters. The language model proposes useful content; deterministic application logic governs consequential actions.

## Packaging for AgentCore Runtime

The runtime adapter exposes a small HTTP contract:

- GET /ping reports service health;
- POST /invocations accepts the bounded coach request;
- the service listens on port 8080; and
- the Node.js 22 deployment bundle contains the compiled entry point and production dependencies.

Model access belongs to a dedicated runtime execution role. The runtime uses apac.amazon.nova-lite-v1:0 in ap-south-1, avoiding an implicit dependency on a model that may not be available in the selected account or geography.

## Keyless production invocation

The browser never receives AWS credentials. TenderLoop’s Next.js route runs server-side on Vercel and uses Vercel OIDC federation to assume a production-only AWS role. The role is scoped to invoke the TenderLoop runtime, and the resulting credentials are short-lived.

This gives us a cleaner operational boundary:

- no AWS secrets in NEXT_PUBLIC variables;
- no permanent deployment key in the hosting environment;
- separate runtime execution and runtime invocation permissions; and
- an auditable cloud identity for production requests.

## Release gates and evidence

We treated public claims as release gates. Before changing the interface from Safe preview to Strands · AgentCore, we verified:

1. the runtime reached READY state;
2. its health endpoint responded successfully;
3. a synthetic end-to-end request reached the runtime;
4. the response identified engine: agentcore;
5. the validated tool was build_study_plan;
6. the response contained exactly three schema-valid study steps;
7. the production UI displayed the AgentCore provenance badge; and
8. the safety contract tests passed.

This evidence is more useful than a vague “AI-powered” label because reviewers and users can tell which execution path actually ran.

## Failure should remain honest

Cloud systems fail, credentials expire, and services can be temporarily unavailable. TenderLoop keeps a deterministic Safe Preview as its reliability fallback. If AgentCore invocation fails or its response does not validate, the application returns the fallback and labels it clearly. It never presents deterministic output as though a model generated it.

The fallback is intentionally less capable, but it keeps the demonstration usable and preserves truthful provenance.

## What remains on the roadmap

AgentCore Runtime is shipped; it is no longer a future milestone. The next production layers are durable, policy-governed family coordination:

- Amazon Cognito for verified users and family-scoped roles;
- Cedar with Amazon Verified Permissions for consent, scope, expiry, and approval checks;
- DynamoDB for plans, Help Cards, consent receipts, caregiver grants, and audit events;
- EventBridge Scheduler for approved reminders; and
- Bedrock Guardrails as an additional model-safety layer, without replacing product policy.

These services will support the same rule demonstrated by the current product: private context stays private, while only minimum-necessary, explicitly approved objects cross roles.

## The lesson

Moving TenderLoop to AgentCore improved more than hosting. It forced us to make identity, tool authority, response validation, fallback behavior, and provenance explicit.

For human-centered agents, that is the real deployment milestone: not merely that the model can run, but that its authority remains understandable and bounded when it does.

Try the live demo: https://tenderloop-two.vercel.app/

Explore the MIT-licensed source and architecture: https://github.com/Pinegrass/tenderloop

Watch the demo: https://www.youtube.com/watch?v=R4wBwO1_0ow