WebinarLive on Oct 29: What a Forward Deployed Engineer Does When Your Pilot Stalls
00Days
00Hrs
00Min
00Sec
Save my seat
Leena AI
Live on Oct 29: What a Forward Deployed Engineer Does When Your Pilot Stalls
00Days
00Hrs
00Min
00Sec
Save my seat
Blog

The first iPhone shipped without a keypad. Why does your AI-native platform ship with an extensive UI?

The day a customer signs, they start paying for outcomes. Why AI-native platforms should ship with less UI, not more, and what Forge changes.

The first iPhone shipped without a keypad. Why does your AI-native platform ship with an extensive UI?

The clock starts at signing

The day a customer signs, they start paying for outcomes. What we usually hand them is a curriculum.

Log in to the LMS. Finish the builder track. Book time with a solution consultant. Learn which tab holds the logs, where the settings live and what each toggle does. Most of that curriculum exists to teach people our screens. Weeks go by before anyone builds something that saves an hour of real work.

That gap isn’t the customer’s fault. It’s a product design choice, and I think it’s the wrong one.

The curriculum vs one sentence

The keypad problem

In 2007, most smartphones came with a physical keyboard. Apple launched the iPhone without one.

The reasoning was simple. Plastic keys are fixed. They sit there whether the app needs them or not, and you can’t change them once the phone ships. A screen can become whatever the task in front of you needs.

Enterprise software is still shipping keypads. Every new feature adds a tab, a toggle, a settings page. The UI only grows, so the learning curve only grows.

AI-native platforms are the worst offenders. The model already understands plain words, and we still make people configure it through forms.

Forms are also built for an average user who doesn’t exist. An HR admin setting up a leave policy and an IT engineer chasing a failed integration get the same screens, in the same order.

We don’t need a copilot. We need an autopilot.

Most products have answered this by adding a copilot. Usually it’s a chat window sitting on top of the same old screens. You ask how to do something, and it sends back a doc link or a list of clicks.

That’s an LMS with a chat window. You still do the work yourself, through the same screens, in the same order.

A copilot helps you fly, but you still need to know the controls. An autopilot flies the plane. You set the destination, watch the instruments and take over when you need to.

That’s my stance. Customers shouldn’t have to learn our controls, or even our words. Nobody should need to know what an AOP, a trigger or an orchestrator is to get work done.

They should be able to say, “If a new joiner’s laptop hasn’t shipped three days before they start, chase IT and tell their manager.” The autopilot works out the trigger, the steps and the systems. It sees the same configs, logs and run history the product sees, so it can act, not just advise.

Forge first, UI later

Forge, our builder agent, is that autopilot for anyone building on Leena AI. Building it changed how we build everything else. A new feature usually starts as a screen: a page, a form, a row of toggles. Docs come next, then a module in the LMS.

We’re flipping that order. Every new feature now starts with one question: how will Forge build it? If a builder can’t get the job done by describing the outcome to Forge, the feature isn’t finished, however good the screen looks.

For us, autopilot-ready means three things. Forge can set the feature up from plain words. Forge can explain it when it breaks. And the screen exists to review what Forge did, not to do the work.

What this looks like in Forge

Forge started life as a debugging agent. Its first job was reading run history and explaining in plain words why a run failed. That turned out to be the smallest part of what it should do.

We’re now building it into the autopilot for everything a builder needs:

  • Discover. Connect your systems, and Forge points out what to automate first. It reads past tickets and inbox queries, groups the repeat requests and matches each to a pre-built flow, or flags it as new work.
  • Configure. Describe the outcome in your own words, and Forge builds or edits it.
  • Understand. Ask why a run failed and get the answer, with the steps that led there, not a raw log dump. Forge shows its reasoning as it works, so you can follow along.
  • Adapt. Forge carries the context of every pre-built AOP. Builders adjust a working flow instead of starting from a blank canvas.
  • Ship. In one partner integration, the only way to promote a build from UAT to production is through Forge.

PII redaction is one of the first features we’re rebuilding this way. Today, setting up a policy means knowing which screen it lives on and which fields to pick. The version we’re building starts with a sentence: “mask salaries and national IDs in every log for the payroll colleague.” Forge drafts the policy, shows you what it will mask and waits for your yes.

We’re also redesigning the studio home around it. You land on a composer, not a menu, and Forge is one click away on every other page.

That’s where Forge is heading. It isn’t a feature anymore. It’s a product line of its own.

Our builders’ success now depends on how well Forge performs, so its performance gets its own report every two weeks.

The UI doesn’t disappear. It moves.

The iPhone didn’t get rid of the screen. It got rid of the fixed keys and let the screen adapt.

Same with an autopilot. The pilot stops working every control, but the instruments stay. The UI stops being the front door and becomes the instrument panel. It’s where you see what changed, scan a run timeline, check a dashboard at a glance and sign off.

That split matters for trust. Enterprise teams don’t want an agent changing things quietly. So the rule we hold ourselves to is simple: you talk to start, you look to check, and nothing goes live without your yes.

Talk, check, yes

What we measure changes too

If the product does the teaching, course completion is the wrong metric. The one that counts is time to first value: how long from signing until a team runs something that saves real hours.

It also changes how we read support tickets. Our support queue has a status called “Not a bug (SOP required)”. Every ticket in that bucket is the product telling us it didn’t explain itself. Under Forge-first, each of those tickets is a job Forge should be able to do.

A question asked twice isn’t a training gap. It’s a product bug. That’s why our docs are now written to be agent-readable, so Forge, or a partner’s own assistant, can answer from them in context. The LMS still has a place for people who want to go deep or get certified. It just shouldn’t be the price of entry.

The bar

Apple didn’t teach people to type on glass. It made the keyboard appear only when you needed it.

That’s the bar for Forge. Tell the product where you want to go, in your own words, and it gets you there. Nobody should have to study it to get their money’s worth.

Hammad
Hammad

Ready to accelerate your Agentic AI journey?

Book a personalised demo
Subscribe to the Leena AI newsletter: the AI Edge Digest, monthly intel on enterprise Agentic AI.
132 West, 31st Street, Suite #1006,
New York 10001
© Leena AI Inc. All rights reserved.