Forward Deployed Engineer, how I deliver it, requirement 6 of 12
AI workflow orchestration
I map the steps, API contracts, and data flows between a customer's systems and the models before I build the workflow.
The requirementDesign the AI workflows, APIs, integrations, orchestration, and data flows that connect a customer's systems to models.
How I deliver it at a customer
- Trace one real requestI sit with the operators and follow one live request through their systems, recording every hop and its owner. That written trace becomes the step list, so we agree scope before I write any code.
- Fix the API contractI publish the versioned HTTP contract first, the way the public API at api.onluca.ai/v1 serves integrations behind bearer keys. Each data endpoint requires a named scope, and the OpenAPI document at /v1/schema lists the scope for each one.
- Encode the planI write the flow as ordered steps in the job engine's format: API call, condition, loop, wait, log, notify, set variable, and abort. In the engine's step runner, an API call step calls the platform's own routes and saves the reply for later steps. The engine stores these steps with each job, but nothing calls that runner yet, so running them is on the roadmap.
- Bind the toolsI expose each action as a tool on the tool bridge, and every tool call runs under a timeout. When a tool declares permissions, a caller who holds none of them is refused before the tool runs.
- Hold risky jobsIn the job engine, infrastructure and data migration jobs wait as pending until a person approves or rejects them. The engine tracks each job but does not run it, so the service doing the work must report the result. A failed job can be retried by hand up to three times by default, and these holds are Early access.
- Ship and watchFor a change that can run beside the old version, I use a rolling deploy on Kubernetes with no unavailable pods. That deploy undoes any rollout that fails or times out. Other changes go out behind a maintenance page, where a failed rollout is undone and the new pod gets a smoke check. A failed smoke check holds the release and pages me, and I read the pod logs in Loki.
Tools I use
| Tool | What it does here | Status |
|---|---|---|
| Tool bridgeAvailable | Refuses a tool call when the caller holds none of the tool's declared permissions, and returns an error when a tool runs past its timeout. | Available |
| Public API, api.onluca.ai/v1Available | Gives integrations a versioned HTTP surface with bearer keys, a required scope on each data endpoint, and 120 requests per minute per key. | Available |
| Multi-provider model gatewayAvailable | Routes model calls through one gateway that holds the provider keys and records the provider, model, latency, and token counts for each successful call. | Available |
| Job engine and approval holdsEarly access | Queues jobs and holds infrastructure and data migration jobs for a person's approval. It does not run jobs itself, and nothing triggers its cron entries yet. | Early access |
| Cloudflare Workers AI (Llama)Demo only | Screens each request with Llama Guard 3, then plans and runs the steps for this page's demo on Llama models. It is not a customer deployment. | Demo only |
Available means shipped and in use. Early access means built but not generally available. Roadmap means designed, not built. Demo only means it powers the public demo, not customer deployments.
Describe a request that takes more than one step. A planner breaks it into two or three steps, each step runs in order with the earlier results as input, and the page shows every step and its latency.
Open the live demoThe other answers
LLM applications in productionOn Luca, model calls normally go through a gateway that holds provider keys, records each chat call and sets a model per task.Prompt engineeringI write the output shape first, measure the prompt against each model's context window, and check replies against that shape.Retrieval-augmented generationChat answers over a customer's own documents, returned with the matched document names, after a check that the caller may use that persona.AI agents and orchestrationI build agents that call your systems through registered tools, still in early access, and workflows that start on business events.Request classification and routingI build automation that classifies each inbound request, plans bounded tasks, and holds high-risk tasks for approval; the dispatcher is in early access.API and integration designI publish the API contract first, gate it with keys and scopes, then build integrations against it.Hybrid enterprise integrationI connect AI services to your identity, applications and data, and run the platform on Kubernetes on Azure Local.Prototype to productionI take a prototype through generated tests and a two-approval merge gate to a production deploy that rolls back if the new pod keeps crashing or cannot start.Approvals and exception handlingIn chat, I hold each Gatekeeper tool marked destructive until the signed-in user approves it, with expiry and a record. This path is in early access.Evals and output validationI built a versioned rubric judge for a tutoring app, and I trace failed or slow model calls to their provider.Client-facing deliveryI turn engineering work into updates that client architects, security leads and business owners can each act on.
Built by Gus Assuncao of Gus IT LLC for a Forward Deployed Engineer application. Luca is the AI platform Gus IT builds and operates. Contact gus@gusit.de. Claude is a product of Anthropic PBC. Cloudflare and Workers AI are trademarks of Cloudflare, Inc. Llama is a trademark of Meta Platforms, Inc. Other names are trademarks of their respective owners. Gus IT LLC is an independent engineering firm and is not affiliated with or endorsed by these companies.