How Delivery Workspace Works: Deconstructing the Collaboration Model That Ships AI PoCs to Production
Most AI PoCs fail at the handoff, not because models are inaccurate. The person who built it doesn't understand the work, and the team doing the work can't parse the code. Delivery Workspace puts the engineer, domain expert, real end user, and data owner into the same space. Working in two-week sprints, you push the system to production together. Here's how Tenten runs it.
By
Tenten AI FDE 團隊
前線部署工程
Published
May 31, 2026
Read time
7 分鐘
Delivery Workspace is Tenten AI's approach to collaborative delivery. You place our delivery engineer, the customer's domain expert, and whoever owns the data in a shared space. Working in two-week sprints, you move an AI PoC from 'looks good in demo' to 'runs in production, used daily by real people, and the team can maintain it.'
This is not a tool. It is not a project plan. What it does is eliminate the handoff, the moment when accountability vanishes and the code stops moving forward.
Why the handoff step kills most PoCs
We looked at the projects that failed. Nine out of ten didn't fail because the models were inaccurate. They failed at the handoff.
The typical sequence plays out this way: a consultant or vendor builds a PoC. The accuracy numbers look clean. The customer signs off after the demo. Both sides approve. The vendor hands the code, deployment documentation, and API keys to the customer's IT team with a simple 'it's yours now.' Three months later you check back. The system sits in staging. No one has moved it into production.
The gap opens between PoC and production precisely where no one owns what happens next. The PoC engineer doesn't know the customer's permission model, doesn't know which audit fields compliance requires, doesn't understand how the actual team works. The customer's IT owns those answers but can't read the prompt logic or understand why retrieval misses cases. Each side holds half the knowledge, and between them sits a handoff document that never gets written completely.
Delivery Workspace exists to solve one problem: that document should not need to exist. The people who know the answers are already in the same room.
Delivery Workspace is a room, not a document
Four roles work bonded together in practice. Our delivery engineer. The customer's domain lead who can make decisions. An actual end user running this system daily. Someone who controls data and permissions, whether IT or security. They share one kanban board, one Slack channel, one deployment environment.
The difference is that the end user enters from week one. Not pulled in at the end for sign-off, but present through every iteration, asking hard questions. A manufacturing project last month was built so the AI would generate a full quality anomaly report. On the third day of testing, the operator said: 'I don't want you writing conclusions. Pull me the three similar cases from our history. I'll write the conclusion myself.' That single sentence rewired the entire product. Under a traditional handoff model, that insight surfaces three months after launch in a satisfaction survey, and by then fixing it costs ten times as much.
Traditional handoff and Delivery Workspace create different outcomes. Set them side by side:
| Dimension | Traditional Handoff | Delivery Workspace |
|---|---|---|
| When users enter | Post-launch sign-off | Week one, every iteration |
| Knowledge transfer | Handoff document | Shared environment, side by side |
| Success defined as | Passes acceptance test | Real people use it daily in production |
| Data and permissions | Patched in later, often blocked | Wired day one |
| When problems surface | Teams blame each other | Same board, same fix |
| Consultant exit criteria | When contract is done | When adoption hits targets and team runs it independently |
Four tracks run in parallel, not in queue
Traditional projects move in sequence: build the model, then integrate, then launch. Delivery Workspace splits into four parallel tracks because sequential work creates delays that matter.
Track one is model and retrieval. You tune prompts, tune RAG, dial in answer quality. Track two is data pipeline. You connect the real customer data, messy as it is, with permission layers intact. This track almost always takes the longest, so you start on day one. You cannot wait. Track three is workflow embedding. You figure out where the AI fits in the user's day, a button, a sidebar, an auto-drafted email. Track four is operations and audit trails. Who can see what, how you trace an error, what compliance audit logs must show.
Most teams focus on track one. Tuning the model feels like 'doing AI.' It delivers satisfaction. Demos look sharp. But what actually blocks production? Almost always one of the other three. Half our delivery engineers' time goes to permissions, compliance hooks, workflow integration, unglamorous work. That is deliberate.
What a two-week cycle looks like
Two-week sprints start on Monday of week one with all four roles choosing which real use case will work by sprint end. A use case, not a feature. Example: 'Customer service reps can pull a one-click summary of a customer's interaction history while processing a return.' That is the target.
The engineer works in the shared environment. Users test continuously. Friday of week two, the end user walks through the system with real data. All four watch. If it works, you push to production for a real user group. If it doesn't, you log which track is blocked and queue it for next sprint.
One metric matters starting sprint one: real adoption rate, not login counts. The percentage of users actually completing real work tasks through it. If that number flatlines for two sprints, the product model is wrong, stop and rebuild instead of adding features. That customer service system that started at 4% adoption stayed polished and broken throughout because no one watched this number consistently.
When to close the workspace
Delivery Workspace does not stay open indefinitely. Exit criteria are strict. The target use case hits adoption targets. The customer's own team can operate it independently. All audit and permission infrastructure is live. Three conditions, all three must be met. Only then does the team hand off full control and step back to on-call support.
These exit criteria exist because we have seen systems die the moment the consultant leaves. If the only reason to close is 'contract ended,' Delivery Workspace is just traditional handoff with delayed accountability. That defeats the purpose entirely.
Every AI deployment at Tenten runs through a Delivery Workspace. The reason is straightforward: a polished demo does not count as success. A project has real value when actual people actually use it daily in production.
One stuck workflow
is enough to begin
Tell us what the team does today, where it breaks down, and what a better working day should look like.