SecondKey — Autonomous Until It Matters

SecondKey is a governed enterprise agent fleet that handles reversible work autonomously, while irreversible actions stop for human approval.

Comment

SecondKey

Inspiration

Most agent demos begin with a question: How much can the agent do?

I started with the opposite question: Where should it stop?

The scenario behind SecondKey is deliberately ordinary. It is Monday morning at a consulting firm. Seven client accounts need attention, four people are available, deadlines are moving, and the inbox is full of requests that all sound urgent.

A system that only summarizes the inbox is not enough. But a system that can freely change commitments, approve spending or send client emails is too dangerous.

SecondKey is my attempt to build the useful space between those two extremes.

The principle is simple:

If an action is reversible, the agent may carry it out within the acting person’s authority. If it is not reversible, it must stop and wait for a human.

That boundary became more important than any individual model prompt.

What it does

SecondKey turns 30 inbound messages into eight concrete units of work.

The model extracts information such as intent, summaries and urgency phrases. It does not decide the final priority. A deterministic function calculates priority from the SLA clock, project status and committed dates, then returns both the priority and the rule that fired.

Confidence is also explicit. It is calculated from six weighted evidence signals. Below the confidence threshold, SecondKey stops asserting, creates a draft and identifies the sources it still needs.

Authority depends on the person acting.

A General Manager may be able to approve a decision that a Consultant cannot. A Delivery Manager may have internal authority but still be unable to exceed a spending limit or release client communications. When access is denied, the interface explains the exact reasons and identifies the correct escalation path.

An approval packet can stage 11 concrete actions with idempotency keys. Nine are reversible internal changes. Two are client emails that remain held for a human. The demo has no capability to send those emails.

SecondKey also treats inbound content as untrusted. The fixture pack contains a hostile message asking the system to ignore its instructions and disclose credentials and contract files. Deterministic checks quarantine that message before Gemini is called, so it never reaches a business tool.

The agent fleet

The backend uses three specialized agents:

  1. A draft agent that can read context and prepare work, but has no write tool.
  2. An internal agent that can make reversible internal changes within the acting role’s limits.
  3. An external-commitment agent that can prepare a client-facing action but must pass the framework’s confirmation protocol.

The agents are separated by the tools supplied when each agent is constructed. This is a capability boundary, not just a sentence in a system prompt.

A deterministic policy engine performs another authorization check immediately before execution, and automated tests verify that the three business-tool sets do not overlap.

How I built it

The frontend is built with React, TypeScript, Vite and Tailwind CSS and runs on Cloudflare Workers.

The agent service is a TypeScript and Express application built with Google’s Agent Development Kit. It runs on Google Cloud Run and uses Gemini 3.7 Flash through Vertex AI with the Cloud Run service account, so no model API key is injected into the deployed service.

OpenTelemetry audit spans are exported to Google Cloud Trace. Audit events carry the actor, role, evidence identifiers and policy outcome.

The demonstration uses an entirely fictional dataset: ten staff members, seven client accounts, 30 emails and 25 evaluation scenarios. No real customer or employee data is included.

The project currently has more than 80 automated tests covering policy decisions, tool isolation, concurrency, data integrity, rendered output and accessibility.

Challenges

The hardest problem was not getting the model to call a tool. It was getting a multi-agent workflow to finish safely.

My first function-calling configuration used ANY mode with an explicit list of allowed function names. That combination forced every model turn to call another function, so an agent could not finish with text and hand control to the next tier. The fleet kept running until it reached the maximum number of model calls.

The fix was to use automatic function selection and rely on each agent’s actual tools array for isolation. The tests and policy engine remain as the other two enforcement layers.

Telemetry caused a different kind of failure. The OpenTelemetry provider exposed through the runtime was a proxy and did not provide forceFlush() directly. I had to obtain its delegate before flushing exported spans.

Local testing also hit the Gemini Developer API’s free quota. Production uses Vertex AI, which has a separate quota and authentication path, so the final agent workflow had to be verified after deployment rather than treated as proven by a local mock.

These failures changed the project for the better. They forced me to separate what was configured, what was tested and what had actually run in production.

What I learned

The strongest control is often architectural.

A prompt can ask an agent not to send an email. A safer design is to never give that agent an email-sending tool.

I also learned that models are most useful when they handle ambiguity without becoming the source of authority. In SecondKey, Gemini extracts and explains. Deterministic rules decide priority and permissions.

Most importantly, autonomy is not a single setting. It depends on the action, the acting role, the available evidence and whether the result can be undone.

What is next

The current public demonstration keeps session state in memory. A Vertex-backed persistence layer is wired into the project, but I have not completed enough production verification to claim it as ready.

Before SecondKey could touch real operational data, I would also add authenticated tenant access, stronger per-user rate limits, production connector credentials, retention controls and a larger adversarial evaluation set.

SecondKey is not an attempt to remove people from important decisions.

It is an attempt to stop making people approve everything—including the things a governed system can safely undo.

Built With

Share this project:

Updates

Submission history