The customer’s chief architect insists on building the agent on their in-house framework, which you think will fail. Respond.

You think his framework will fail. He thinks yours will be an orphan his team has to support after you leave. You could both be right, and an argument about merits cannot settle it. Move the disagreement from opinion to evidence: Ask why before you answer. What does the framework already give them: their identity, logging, deployment pipeline, on-call team? Those are real costs of going outside it. Acknowledge the reasons out loud. “A standard means your team can run this after we leave. That matters more than which library is nicer.” Turn your worry into failure modes you can test. Not “it won’t scale”, but the specific paths you expect to break, each tied to a mechanism he can check: a tool call that times out mid-plan (can the tool adapter pass an idempotency key, so a retry doesn’t write twice?), state across a long conversation, tracing each step, adding a tool without a release. Propose a short test that decides it. Both options built thin on the hardest path, with the same tasks, the same data, and pass criteria you both sign before anyone writes code. Pick criteria where the frameworks differ, not ones that measure the model. Say in advance what you will do with each result. If his framework passes, you build on it. If it fails, you agree on the fallback, such as your SDK wrapped behind his framework’s interfaces. Record the decision. Options, criteria, result, the risk you accepted, and the event that would reopen it. When the test favors him, say so first and commit fully: no “I still think”. He runs this platform after you leave, and a test he helped design is one he will defend. Customer disagreements like this one are taught in Client simulation and customer judgment. Its first lesson, what customer rounds look like, is free; the lesson on the moves inside a hard conversation (own it, acknowledge, offer options) is in Pro.

Disagreeing with the customer’s architect

A practice prompt we wrote. No company or candidate report names it, so it carries no company tag.

How to answer

You think his framework will fail. He thinks yours will be an orphan his team has to support after you leave. You could both be right, and an argument about merits cannot settle it. Move the disagreement from opinion to evidence:

Ask why before you answer. What does the framework already give them: their identity, logging, deployment pipeline, on-call team? Those are real costs of going outside it.
Acknowledge the reasons out loud. “A standard means your team can run this after we leave. That matters more than which library is nicer.”
Turn your worry into failure modes you can test. Not “it won’t scale”, but the specific paths you expect to break, each tied to a mechanism he can check: a tool call that times out mid-plan (can the tool adapter pass an , so a retry doesn’t write twice?), state across a long conversation, tracing each step, adding a tool without a release.
Propose a short test that decides it. Both options built thin on the hardest path, with the same tasks, the same data, and pass criteria you both sign before anyone writes code. Pick criteria where the frameworks differ, not ones that measure the model.
Say in advance what you will do with each result. If his framework passes, you build on it. If it fails, you agree on the fallback, such as your SDK wrapped behind his framework’s interfaces.
Record the decision. Options, criteria, result, the risk you accepted, and the event that would reopen it.

When the test favors him, say so first and commit fully: no “I still think”. He runs this platform after you leave, and a test he helped design is one he will defend.

Customer disagreements like this one are taught in Client simulation and customer judgment. Its first lesson, what customer rounds look like, is free; the lesson on the moves inside a hard conversation (own it, acknowledge, offer options) is in Pro.

Follow-ups

What the interviewer may ask next, once your first answer is on the table.

He says: ‘Our framework is the standard here.’ What do you acknowledge?
Design the test that would decide it within a week.
The test favors his framework. What do you do?

Where answers go wrong

Argues framework merits instead of proposing a cheap test that decides it.

Answer this in two minutes

Write the answer you would say out loud. The clock starts with your first word.

Compare with the model answer

Model answer

“Before I push back, help me understand the standard. What does building on your framework give you that I’d be taking away?”

He says every service in the company uses it, it plugs into their , logging and deployment, and his team supports it at night.

“That’s a strong reason. If we build outside it, your team inherits something they don’t know how to run, and that cost lands after I’m gone. I’d weigh it heavily too.

“My concern is narrower than ‘it won’t work’. This has to plan across several tools, retry a tool that times out without repeating a side effect, and keep state across a long conversation. Here’s the specific worry: from your docs, the HTTP tool adapter has a fixed 30s timeout and no way to pass an through, so if an update to a customer record times out and we retry it, the record could be written twice. I haven’t seen how your framework handles the other two either. Those three are the paths I expect to break first, and I might be wrong about all of them. So rather than argue, can we test exactly those three paths this week? It costs one engineer from each side for a week. If you agree, let’s tell your sponsor together today that this doesn’t move the launch date, because the winning thin build becomes the first slice.”

The test. Built thin on both, same inputs, criteria agreed before any code:

duration: >-
  5 working days, one engineer
  from each side, pairing
tasks: >-
  30 real tickets from last month,
  chosen by his team
paths_under_test:
  - >-
    multi-step plan across 3 tools
    (lookup, update, notify)
  - >-
    tool timeout injected on "update",
    then process restart; the retry
    reuses the original idempotency key
  - >-
    conversation of 40 turns; state
    survives a process restart
pass_criteria:
  task_parity: >-
    same model and prompts on both;
    success within 2 tasks of each
    other, graded by his team
  no_duplicate_writes: >-
    0 across all injected timeouts
    and restarts
  trace: >-
    every tool call visible in their
    existing logging
  new_tool_cost: >-
    add a 4th tool in under half a day
decision_rule: >-
  his framework is the default; ours
  only if his fails a criterion ours
  passes

Task success tests the model, not the framework, so it’s a parity check, not a gate. The other three criteria are where the frameworks differ.

“The decision rule leans your way on purpose. If both pass, the standard wins. If yours fails one of them, I’ll first try to fix that path inside your framework: a retry wrapper, a state store. If that takes more than two days, we run our agent SDK behind your framework’s interfaces, and it runs on your SSO, logging and deploy pipeline, so your team still runs one stack.”

If he says, “Our framework is the standard here”: “Agreed, and I’m not asking you to leave it. I’m asking which of these three paths it handles today, and the test tells us. Anything it needs added, we build inside your framework, and your team keeps it.”

If the test favors his framework: “It passed all four criteria, so we build on it, and I’ll say that in the steering meeting. I was wrong about the timeout path. The one thing I’d add is the duplicate-write check as a permanent test in your pipeline, since that is the failure I care most about.”

If both fail the same path: “Then the problem is that path, not the choice of framework. Yours stays the default, so we fix the path inside it and rerun the test on it before we build anything else.”

If he won’t spare an engineer, or refuses the test: “Then I don’t want this to become my view against yours. I’ll write the three failure paths and both options on one page, and ask your sponsor to decide with you in the room. Whatever is chosen, I’ll build on it, and the page goes into the decision record so the risk we accepted is written down.”

Recording it. The same day, I write a short decision record in Michael Nygard’s architecture decision record format: a title, the context (where I put both options, the criteria and the test results), the decision, its status and its consequences. I add a revisit trigger: if we need a tool the framework can’t call, we reopen it. He reviews it before it goes to the project channel, so the record is ours, not mine.