Silverpond

How it was earned

The ambiguity

The brief was one paragraph: let operators talk to an agent about a case, have it look up the right data, and let people add what they learn. It didn't say how to split that work across the systems involved, or how to keep it safe for every customer after the first. That split was the question I took to the senior review.

I didn't want to hold anyone's keys

The simple path was to ask each customer for an AWS access key and store it. I didn't want us holding anyone's permanent credentials. Instead the platform borrows a role in the customer's own account for an hour at a time, tied to that customer so it can't be replayed against another and the standard defence against a confused-deputy attack. The customer can revoke it whenever they like, and setup is a stack they launch themselves plus two values and one choice.

Four things I assumed, and what the system actually did

All four are about how Anthropic's managed agents and AWS behave in public, not about anything internal. Each cost me a day and changed the design.

• A managed agent isn't a text stream. It sends a run of events like tool use, waiting, results before any message, so the client had to be a stateful workflow.
• One deployment can't do everything. The agent's environment can only be created after the role it depends on exists, so setup became two phases.
• Connected isn't authorised. A healthy worker still couldn't run commands until its tools were attached when the agent was created.
• Memory belongs to the agent, not the chat. Memory stores outlive a conversation, so storage had to be managed separately from chat sessions.

Two product's features were being treated as one

Claude's managed agents and Amazon Bedrock overlap and are easy to conflate. I compared them, recommended managed agents, then tried both ways of running them: a worker in the customer's own account, which keeps their data at home, and Anthropic's hosted sandbox, which costs less to run. Which one matters more is the customer's call, and usually it's where their data lives.

Prototype before production

I built the workflow in FastAPI first, a stack I could move fast in, so the design could be proven before anyone committed to changing the Rails product.

Scope was enforced in code, not asked for in the prompt

Queries that should never run, such as one reaching for infrastructure the agent has no business touching, are classified into tiers before the model acts, and refused in 3.3 s with zero tool calls.

The agent was slow because it was free to wander

Left to search the knowledge base however it liked, the agent wandered. Turn one reads only the index; turn two reads at most two files, in parallel.

The whole arc, in order

1. SAWThe brief was one paragraph. It didn’t say how to split the work across three systems, or how to make it safe for the second customer, let alone the fiftieth.
2. SAWThe obvious path was to ask each customer for an AWS access key and store it.
3. CHANGEDThe platform assumes a role inside the customer’s own account instead, tied to an identifier bound to that customer, so one tenant’s trust can’t be replayed against another’s. The credentials last an hour and the customer can revoke them at any time.0 keysstored
4. CHANGEDSetup became a stack the customer launches themselves, then two values typed in and one option chosen. Everything after it is automated.~2 minof the customer’s own clicking · projected
5. CHANGEDThe design was proven in a FastAPI prototype and reviewed before anyone changed the production app.
6. HOLDSThe agent’s first-turn search, once retrieval read an index before it read files.23.4 s → 3.9 srepeated runs
7. NOT YETHow the agent should tell which case you’re asking about was never settled while I was there. It could take an explicit ID, use the most recent one, or infer it.

What stands

• An architecture review the senior team could decide from.
• The integration into the production app, carried a component at a time with the senior engineers. The architecture and the system design were mine.
• Onboarding reduced to two values typed in and one option chosen, with zero stored AWS credentials.

What it still didn't do

• My placement ended before the integration was finished. The design and the prototype were complete; carrying it the rest of the way was the team's.
• How the agent should decide which case you mean was never settled. It needed an explicit case ID before it would answer, which suits a link into a case and not someone just asking a question.

Sources

• Internal to Silverpond.