The moment a customer types "just build me a company intro page" into a chat window, that single sentence has to travel through several invisible steps before it becomes actual work. The one orchestrating all of this is ONTLE's AI PM — an AI (project manager) that ONTLE assigns to each customer project, one per project, to act as the point of contact.
In this post, we trace exactly how that one "intro page" request flows from the first message to completion — and, at every ambiguous moment along the way, what the AI PM uses to decide.
ONTLE's structure clicks into place if you think of a restaurant.
A guest places an order in plain words with a server ("one of the spicy ones, but go easy on the heat"), and the server translates that into a standardized order ticket and sends it to the kitchen (dish name, spice level, table number). The kitchen hangs the tickets in order, cooks them, and serves each dish to the guest when it's ready. If the guest says "this is too spicy," the revision request goes back into the kitchen.
The key thing here is that not every word exchanged with the guest becomes a ticket. Small talk like "nice weather today" or a question like "which is better, the spicy one or the mild one?" gets answered on the floor and ends there. The server writes a ticket only for the words that are clearly a real order — in other words, an actual request for action.
And a good kitchen remembers its guests. It recalls a note like "less salty than last time" or a regular's preferences and factors them into the cooking. In ONTLE, the thing that plays the role of this memory is Knowledge ONTLE — a setup where the material a customer has accumulated in ONTLE over time gets pulled back out and referenced by whoever carries out the work. (We'll see it in action in Step 4.)
The AI PM is essentially this restaurant structure ported almost directly into software. Conversation happens on the floor; the actual work is handled in the kitchen (the task queue). Now let's follow how "just build me an intro page" passes through this kitchen, in six steps.
Say a customer types "just build me a company intro page" into the chat. Customers don't use commands — they talk the way they normally would (natural language). The first thing the AI PM does is work out whether this is just thinking out loud or an actual request to act on. If it decides this is a request, it asks back about anything missing.
For example, "are there a lot of services like this these days?" is a question that ends once it's answered, so it doesn't turn into work. On the other hand, "build an intro page and show it to me by next week" contains both a what (an intro page) and an action verb telling you what to do with it (build it). When an "object + action verb" pair shows up together like this, it's treated as a request candidate.
Our example, "just build me an intro page," has both an object and a verb, so it's a request candidate too. But what kind of company it's for and what it should contain are left blank. So rather than deciding on its own, the AI PM asks once more: "I'll build you a company intro page. What would you like it to include?" If it pushed every single sentence into the work queue, even "hello" would pile up on the list; conversely, if it let a real request slip by as small talk, nothing would ever happen.
The customer replies, "I'd like a company intro, contact info, and a simple inquiry form." The AI PM then organizes this conversation into a draft brief. It's the same as the server transcribing the guest's "spicy one, easy on the heat" onto the ticket form. There are usually four fields to fill in.
| Field | What it means | Example |
|---|---|---|
| Purpose | Why this work is needed | To introduce the service to new customers |
| Features | What it needs to be able to do | Company intro, contact info, inquiry form |
| Scope | How far it goes and what's left out | No payment features; static intro only |
| Form | The type of deliverable | One web page opened at a dedicated address (subdomain) like 'companyname.ontle.kr' |
Here, a "subdomain" is a dedicated address created by adding a name in front of a larger site address. The AI PM doesn't finalize this draft on its own. It's a checkpoint — the draft is shown back to the customer for confirmation. If anything's missing, this is where it asks back, like "should the inquiry form deliver submissions by email?" If you take just a one-liner — "make me a website" — and start right away, you end up with a repeating "that's not what I meant" later; but by aligning the four fields of purpose, features, scope, and form up front, you catch those mismatches early. Only when the customer says "yes, that's right" does it move on.
The moment the customer confirms the brief, the request gets a unique number and is formally placed on the task queue. In our example, let's say it came up as '#123'. From here on, all communication (progress questions, revision requests) runs on this number.
At this point, the pre-registration brief confirmation and the post-registration 'In review' play different roles. Confirming the brief is the agreement with the customer step, where the customer stamps "yes, this order is correct." 'In review,' on the other hand, is the hands-on review step, where whoever actually builds the request (the 'worker' we'll meet in the next step) re-examines the scope and features and checks whether there's anything technically unworkable. If more missing information turns up here, the AI PM asks the customer once more.
ONTLE calls the execution program that actually processes a queued request a worker. This is the scene where a cook reads the ticket in the kitchen and starts cooking. Drawing on the power of generative AI — which produces text and code — the worker builds the deliverable according to the purpose, features, scope, and form written in the brief. The deliverable varies by the requested form.
At this step, the worker that picked up #123 consults Knowledge ONTLE. Instead of stamping out a run-of-the-mill company intro page, it pulls back out the brand guide and product list this customer shared earlier and builds an intro page that fits that company's colors, logo, and product descriptions — one that actually looks like "us."
The kitchen doesn't always run smoothly, either. If the brand material to reference is too thin and the worker gets stuck partway, the request doesn't quietly vanish or get forced over to 'complete.' It stays parked at 'In progress,' still visible to the customer, so it can ask again what more is needed.
A draft of the intro page coming out doesn't automatically make it "complete." The status changes to 'Awaiting confirmation,' and the deliverable is handed to the customer. This is the moment the dish is served to the guest. Having this one slot — which gives the customer time to open it up and judge for themselves — is what prevents the accident of a deliverable that misses the intent getting marked complete on its own.
If the customer approves the deliverable, the status changes to 'Complete' and the request wraps up. If instead they say "could you make the logo color a bit darker," it becomes a revision request, goes back to the worker, and Steps 4–5 repeat.
At this point there's one line the AI PM has to draw: is this a revision, or a new request? The yardstick is the 'scope' from the brief agreed at the start. "Make the logo darker" is a touch-up within scope, so it's reworked while keeping #123 as is. But if a few days later the customer says "add payment features too," that falls outside the scope agreed as "no payment features." So rather than cramming it into the existing request, it's split off as a separate request with a new number.
This is the core principle for cutting off, at the source, what's considered the most common cause of failure in project management: 'scope creep' — the phenomenon where the work scope agreed at the start keeps quietly swelling as more demands get added. This is where you stop "just one intro page" from ballooning into something unrecognizable, bolted-on piece by piece, until the work has no end in sight.
Here's the set of statuses a single request passes through inside the queue.
| Status | Meaning | What happens in this status |
|---|---|---|
| New | The brief was just registered | Request number assigned, awaiting worker assignment |
| In review | The worker re-confirms scope and features | If information is missing, the customer is asked again |
| In progress | The worker is building the actual deliverable | Produces the deliverable as a document, web page, or app |
| Awaiting confirmation | The deliverable is out and waiting on the customer | Customer is notified, deliverable delivered |
| Complete | The customer approved it | Request closed, deliverable finalized |
| Revision requested | The customer wants changes | Returns to In progress and repeats |
Customers can follow in real time, on screen, which slot their request is in right now.
If the AI PM read it as a question, answered it, and stopped, just say it again with both an object and an action verb. Instead of "can you do this?", try "then go ahead and build it with this." Once a "what + build/revise" is attached, it moves to the brief stage.
You don't have to fill them all in from the start. Just tell us what you know, and the AI PM will look at the blanks and ask back — "how should we handle this?" — to fill them in together. That said, if you settle the 'form' (web, app, document) first, the brief gets finalized faster.
Once a number is assigned, you can check the current status anytime from the chat window or the request list. Without having to peer into the task queue or the code yourself, "which step it's at right now" is always on display.
Just write the types you need together in the 'form' field of the brief. Keep in mind that the more types there are, the more there is to check at the 'In review' stage — so spelling out the form concretely from the start is faster.
In the end, a good AI PM isn't an AI that quickly answers "yes, got it," but one that pauses you once to ask, "is this really what you want?" From "just build me an intro page" becoming #123, becoming a deliverable dressed in brand material, and splitting into revisions and new requests — this single "one more check," placed at every junction along the way, is the heart of the trust that turns passing words into work you can be held to.
Author: Jung Yuna