Why enterprise AI needs FDE over consultants: the accountability question

When a consulting project closes, traditional consulting firms hand over a 180-page deck and an implementation roadmap. Everyone's satisfied. Three months later, the deck sits in a shared folder. No code runs in production. No business units changed their workflows.

This isn't an exception. It's built into how consulting firms operate.

FDE vs. traditional consultants: this isn't about capability, it's about delivery

Traditional consulting firms hire smart people. Industry analysis, process diagnostics, change management frameworks, they have real expertise. The issue isn't capability. What determines their delivery is their business model. They sell advice. They price by billable days and reports. Their contract acceptance criterion is document delivery.

An FDE, Forward-Deployed Engineer, sells something else entirely: a system actually running in a customer's environment with people using it. The engineer embeds directly, sits in customer meetings, connects to their database, and carries the AI workflow through to production and adoption. Acceptance isn't measured in deck pages. It's measured in whether anyone's actually using it.

One question separates them: who's still accountable for adoption rates after the project ends?

With consultants, the answer is usually nobody. Report delivered, payment cleared, relationship moves to the next proposal cycle. Whether the advice actually landed, whether adoption rates hit 4% or 40% after launch, that's outside the contract and not part of the pricing model. With FDE, the answer must be us. Delivery is defined as a working system with actual adoption. Low adoption means we haven't delivered. We don't get paid.

The last mile isn't add-on work, it's the engineering

Most enterprise AI implementations don't fail on model selection or architecture diagrams. They fail at the last mile nobody wants to own: data cleanup, permission scaffolding, legacy system integration, process redesign, and getting employees to actually open the tool instead of working around it.

Consulting firms label this phase: 'implementation execution: recommend customer IT team lead.' One sentence. That puts the hardest, messiest, most engineering-intensive work directly on the team with the least bandwidth to handle it. You've paid premium rates for the right advice. Then you realize you need to spend that much again to make the advice actually work.

FDEs see it differently. The last mile is the engineering. We worked with a manufacturing company where the previous consultant's knowledge base architecture was sound, RAG selection was appropriate. But nobody had processed their 30 years of accumulated documents (messy formats, handwritten scans, chaos). The system couldn't retrieve anything. Our first step wasn't redrawing the architecture. It was spending two weeks building the data pipeline and cleaning the data. Then the same architecture worked.

The honest trade-offs

FDE isn't a silver bullet. It's slower, more expensive, harder to scale because it requires deploying actual engineers, not copying deck templates. If you need just a board-ready report or a competitive analysis, traditional consulting is more cost-effective. Skip FDE for that.

But if you need a system running in production with actual users, handling real traffic and real data, then you need someone accountable for those usage numbers after the project closes.

That's how Tenten operates. Engineers embed, carry accountability through production and adoption. A beautiful demo doesn't matter. Production with real usage does.