Forward Deployed
Engineering

Who you become. A developer executes the task he was given. An architect decides what the task should be, chooses the solution, and owns the consequences. These are different professions, and the second one starts with a different way of thinking.

Why discovery comes before code. A decision made without understanding the process and the data turns out technically flawless and useless. What fails most often is not the implementation but the choice of task.

Questions you ask yourself. Before the task: whose work does this change, and have I spoken to that person. Before the decision: what happens if I'm wrong, and how will I notice. After delivery: does this work without me.

Questions you ask others. How to test someone else's technical judgment: ask them to name where the solution breaks; ask what happens at ten times the volume; ask which option they considered and rejected. Anyone who can't answer those three hasn't thought the task through — human or agent.

The three-step rule: never say "no" or "I don't know" on the spot. In a first conversation an architect neither refuses nor admits ignorance. The sequence is:

• "I'll check, I'll look at it from your side, I'll talk to a specialist" — with a deadline and a commitment to come back.
• If an alternative is visible, offer it rather than staying silent.
• Only after the check: a reasoned "no," with an explanation of exactly what was tried.

A refusal without the first two steps reads as incompetence. A refusal after them reads as expertise.

Standing with the client. When an architect says "that can't be done," it should be accepted without argument. That standing is built from a history of checks: the client watched you search for a solution and knows the refusal isn't laziness. Without it, every "no" turns into a negotiation.

The right to say "AI won't solve this." Rejecting the wrong solution is part of an architect's job, not an evasion of it.

This lesson comes back at every defense: what gets tested there is not only the system but the ability to justify a decision under pressure.

How to listen to someone who describes a job description instead of actual work. Open questions versus closed ones. Why "tell me about your processes" produces a useless answer. How to look for contradictions between accounts, and what to do with them. The cardinal mistake: proposing a solution before you understand the process.

What has to be captured by the end: data state and quality, volumes and frequency of operations, integration points, access and privacy constraints, and who physically works with the system.

The architect's primary tool during discovery.

A process described in words does not convert into a solution. "I copy from this tab into that one" says nothing about what to build. So the process isn't retold — it's reproduced: you open the same spreadsheets and programs the employee works in and walk through it on screen, step by step.

That's when what the words don't carry becomes visible: which fields, which data types, where a conversion is needed, where a relationship between tables replaces a manual transfer. When a process can't be shown on screen — a phone call, a note in a chat, something passed along verbally — it gets drawn as a diagram together with the participant.

The diagram then works as a stencil for the build: it shows which data comes from where and in what type. Without it, the agent builds the system on an approximate understanding of the process, and the errors surface during rollout.

Which systems are already in place, where the data sits, what condition it's in. What the API exposes and what it doesn't. Whether there's a cloud version, and whether data syncs between accounts. Closed and legacy systems: when integration is impossible and the solution has to be built alongside rather than inside.

Separately — other contractors: what they have already implemented, how it was done, and why their work has to be unpacked before yours begins.

A technical check before a commitment reaches the client: what's buildable, what isn't, what's buildable differently. A refusal at this stage is cheaper than a refusal in week four.

The framing: what changes, what measures it, what counts as success, who confirms the result. Baseline figures are captured before work starts — processing time, share of manual steps, error rate — and measured again at the end.

The prompt formula: task → role → goal → context → format. Structured output instead of prose you have to parse afterwards: the schema is defined up front and the model returns data, not text. The decision is made once and eliminates an entire class of failures.

The company's BusinessBrain: operating rules, tone, nomenclature, constraints, standard cases — assembled from the case documents. What lives where: system prompt, project files, database. Privacy: what must never go to a model, and what the alternatives are.

A rule, a lookup table, ordinary code — cheaper, faster, more reliable. How to make that call before you start building. Choosing the model for the task. Cost at the case's real volume; latency as a constraint.

Criteria for assessing a service: is there an API and are there integrations for moving data, is there a cloud version, does data sync, how does support behave, what are the response and input speeds, what does it cost at real volume.

A fallback service for every critical component. The interchangeability rule: keep two or three viable services per operation — when one fails, quality may drop but the system doesn't stop.

Budget is calculated in iterations rather than months: 5,000 / 10,000 / 15,000 / 20,000 operations, and the client picks the volume. A dedicated card for subscriptions, with invoices routed automatically to the client's email so nobody has to dig them out of each service by hand.

Project structure: where the data lives, where the logic lives, where the interface lives. Reading a diff — what changed and what that changes in behavior. How to read an error and find the line. SQL at the level of SELECT and JOIN: agents get data wrong quietly — a bad JOIN doesn't crash the system, it puts wrong numbers in the client's report.

Calibration exercise. Twenty lines written by hand. Not for production. The point is to feel what costs ten minutes and what costs a week. Without that reference you cannot estimate effort, and you cannot catch the moment an agent over- or under-states difficulty.

Repository, access, development and production separated from day one. Backup before any change. Rollback in a single command. Secrets outside the repository and outside the model's context.

Red lines — what an agent never gets: running as root, deleting data in production, migrations without a backup, changing permissions, secrets in plain text. This is the condition for being allowed near a production environment at all.

The prototype is built before the main implementation starts and shown to the client. It has one purpose: to move the conversation from talk onto a screen. In conversation a client agrees to anything and remembers his requirements later; in front of a prototype he sees what he's getting and speaks up immediately.

What to show: data entry, the main screen, the shape of the output. What not to do: polish the prototype into something workable — it gets thrown away.

Plan before code. Decomposition: why "build me a platform" fails and "add one field" works. Acceptance criteria are written before the run. One change per pass.

One task end to end. Reading the diff at every step, accepting or rejecting. What to do with garbage on input. An interface for someone who never read the documentation. Verification against last month's data from the case export.

Data migration happens outside working hours — when nobody is entering records and nobody is touching the system. The team moves to the new solution at the start of a working week.

Technical operating instructions: what to do on a routine error, where to find logs, who to escalate to. Measurement afterwards, compared against the baseline. The list of "what we still had to do by hand" is the requirements list for the future platform.

Entities, relationships, the lifecycle of a record. Where the truth lives. What happens with a second client and ten times the volume. Why the schema can't be handed to an agent without a decision already made: this is what it does worst and what costs the most to redo six months later.

Changing a schema against live data. A backup as a precondition. Working with a real case export: duplicates, gaps, the same field in different formats, junk in reference tables. The agent cleans; you reconcile against the source.

Syncing with the client's running systems: the data must match cell for cell and column for column. That's the baseline minimum — without it automation is simply not possible.

A specification as a document, not as a chat thread. What's in scope, what's out, what the acceptance criteria are. Persistent project rules get written when the agent makes the same mistake twice. Path-scoped rules — when a rule is only needed in part of the project.

Entity → relationships → permissions. Acceptance piece by piece: the agent does one thing, you read it and accept it, then the next. Why a hundred lines without a commit is a failure even when everything works.

What to look for in a change, which edits you can accept at a glance and which demand a close read. The change log as a mandatory artifact.

A skill gets created when you paste the same instruction for the third time. A subagent — when a side task clutters the thread. Context: rules load always, skills on call, subagents separately. Bloated rules make the agent less attentive.

Every block and every phase of an automation is labeled as it's built: what it is, what it's for, what happens if it fails. It's written for you, not the client: in two or three months you'll come back to this system and won't remember the logic.

This is what makes a system transferable and extensible. An unlabeled automation gets rewritten from scratch — that's cheaper than deciphering it.

The calculations and rules that used to live in an employee's head. Generating documents and reports from the same data.

An instruction in the rules is a request. A prohibition is permissions and hooks, nothing else. A hook belongs where something must fire every time, regardless of what the agent decided on this particular run. Permissions are configured before the first production access, not after.

How to estimate the effort of a task an agent will carry out — based on the week-three calibration. Technical difficulty and volume of work are different things: a hard solution can take an hour, a routine one three days.

Separately: what to do when a requirement arrives after the data model has already been designed. Which changes fit into the existing solution, which require rebuilding the foundation, and how to tell them apart before work begins. The output is an assessment — "this fits" / "this requires rebuilding that part" — and the decision about schedule and cost is not the architect's.

When RAG is needed and when a file in context is enough — decided by volume and update frequency. What gets indexed, how it's chunked, which metadata. Citations: the rule is "no source, no answer." What to do when the answer isn't in the corpus. Re-ranking and hybrid strategies — at the level of "when to start thinking about it."

APIs, JSON, response codes, retries, timeouts. Webhooks and idempotency: why the same webhook arrives twice and what to do about it. A standard connection protocol versus a hand-rolled connector — when each is cheaper.

What problem they solve and when you can't do without them.

A separate stage of work, triggered when a project lands in an unfamiliar industry or country.

Micro-automations to test services. Before the main build begins, small throwaway automations are assembled — their job isn't to work but to measure: data entry speed, response speed, quality of the service's support, real cost. Based on the results the service is adopted or dropped.

Regional constraints. Which services are blocked or unavailable, what data residency requirements apply, where an intermediate layer will be needed. A solution that works in one country may be entirely inapplicable in another — and that gets established before design, not during it.

Schedule buffer. In an unfamiliar industry or country, the first two or three weeks go on discovering what you didn't know. That is built into the estimate up front.

Your stage. Every scenario is run 10–20 times with varied inputs before anyone outside sees the system. This is where the bulk of errors are caught.

The client-team stage. Demo access is opened and a deadline for feedback is set — two days to a week. You need 30–50 touches from live users for the real problems to appear; fewer than that and the sample means nothing.

Separately: awkward and deliberately hostile inputs. Empty fields, text where numbers belong, double submissions, interruptions halfway through. Who checks these, and against what list.

Three levels, each with its own behavior:

Classification by the nature of the error: what's fixed by the prompt, what by the data, what by the code, what by the process. An error that can't be fixed — how to surface it to the user. The iteration cycle: hypothesis → change → run → decision.

A system is never fully finished. Polishing it internally, without live users, hits a ceiling: beyond a point you stop finding errors, because the errors are produced by people, not by you.

The benchmark is roughly 60–80% of errors eliminated, with no critical ones remaining. At that point the system ships, because a week with live data yields more than a month of solo refinement. The release decision belongs to the architect: he's the only one who sees the real state of readiness.

What must be in place first: rollback, monitoring, alerts on the sensitive components.

What the agent does: connection, installation, configs, processes, schedules, logs, the deploy command. What you decide: what gets deployed, where the line between test and production runs, which processes stay alive, what counts as an incident. What's never handed over — the week-three red lines, now in practice.

The sequence for putting a new version into production: what to verify beforehand, in what order to switch over, how to confirm the system is alive afterwards.

Separately — the rollback plan: how to return the previous working version in a single command if the new one has broken the client's process. If that plan isn't written, you don't release. Plus credentials and keys: where they live and why not in the repository.

Launch day. Be reachable from the moment it goes live — questions are guaranteed. First check: does everyone actually have access, because someone always didn't get it. First-day feedback is worked through within two or three days, not later: otherwise people revert to the old way of working.

What to log and what must never be logged. Alerts on the sensitive components — the parts whose failure stops the process. Tracing the chain: where exactly the meaning was lost. A one-page dashboard for the client.

Failures: the model is unavailable, the quota ran out, garbage came in, the response wouldn't parse, an external service changed its format. Degradation instead of collapse — switch to the fallback service; quality may drop, but the process keeps running. The human in the loop: where it's mandatory and where it does harm. Caching and a cheaper model on the simple steps.

What counts as an incident and what counts as a routine error. The sequence: alert received → cause identified → fix or service swap → verification → write-up for the client.

When you don't tell the client about a failure: it was non-critical, the fallback handled it, the process was unaffected. When you always tell them, in writing: the process stopped, data was corrupted, or the cause hasn't been removed and may recur.

A special case: a constraint you can't lift — a service is unstable for reasons outside your control. That gets stated plainly, with the options laid out: wait for an update, change the approach, drop the feature.

How it differs from a development agent: nobody supervises it in real time, and the cost of error is the client's data. When an agent is warranted and when a sequence of steps is enough. The boundaries of its authority: what must never be delegated to it.

Separating logic: one scenario, one agent. A voice agent, an outbound campaign, document processing — these are different logics and must not be merged into one build. If two people work on the system, the split follows scenario logic, not slices of a single scenario: one builds the foundation, the other builds the automation chains.

Proposes → executes with confirmation → executes on its own. Who raises the level and against what criterion. The threshold is set in advance; otherwise it gets raised out of impatience.

The full contents of the package:

• access: accounts, password manager, keys, who owns what;
• what the system is made of: which service is responsible for what, and how they connect;
• subscription cost per service and what happens if one goes unpaid;
• technical documentation: architecture, data model, integration points, known limitations;
• operating instructions: routine failures, where the logs are, how to roll back;
• the development agent's configuration, packaged — otherwise it leaves with you.

If the client has a technical team, a knowledge base over the system is added, so they can query it directly. If they don't, handover is limited to documentation and instructions — and that's agreed in advance.

Knowledge transfer takes anywhere from a week to a month and a half, depending on how strong the client's technical side is.

A client will want a mobile app, a desktop app, or something on a different toolset entirely.

What transfers completely: the working cycle, briefing the agent, decomposition, acceptance criteria, environment separation, backups and rollback, evaluation sets, reading diffs, red lines.

What needs separate handling: platform constraints — app store publication, permissions, offline behavior, OS versions, screen sizes. The agent knows about these and is at its most confidently wrong precisely here.

The entry procedure: establish the platform's constraints in a dedicated conversation before work begins; build a minimal end-to-end slice and get it running on a real device; record in the project rules every place the stack behaves unexpectedly; add a buffer to the estimate.

The quality of your first piece of work on an unfamiliar stack will be lower than on your own. That's said to the client before, not after.

Two or three systems in flight at once is normal. Four is a risk, and it has to be said out loud before the schedule slips.

The sign of overload that shows up before anything breaks: initiative disappears. The person stops checking services, stops looking for alternatives, stops clarifying what's unclear — and only does what was asked. That's a signal to stop, not to push harder.

An architect tracks his own load himself, because it can't be assessed from outside: only a technical specialist can judge technical work.

An unfamiliar case from a different industry. Visual process diagrams, systems landscape, feasibility assessment, task framing.

From task to working prototype. Everything done across eleven weeks, compressed — this tests the method, not your speed.

Architecture diagram, before-and-after figures, demonstration. A review of the decisions taken: what was chosen, which alternatives were rejected and why. A portfolio of two systems with architectural documentation.