LOCKEDIN / FORWARD-DEPLOYED ENGINEERING 101
Understand it.
Then build it.
You can be an experienced engineer and still be new to agents. Start with what each thing is and how it helps a person do useful work. Explore 58 original introductions across software, agents, cloud, security and delivery. Start here without a model key; each topic connects to deeper instruction and practice.
A place to start.
Choose a short reading route, or look up a concept below.
- 101UnderstandPlain language, visual walkthrough, vocabulary
- 102Build with guidanceOriginal lessons, examples and knowledge checks
- 103Practise and explainRunnable labs, failure cases and handover
Connect the software
Follow the library code that turns a convenient method call into an API request.
See the 9-concept route
For people who want the software vocabulary behind AI tools, or a refresher before their first local build.
- 01Terminal & CLIBegin with a person issuing a command to a program; the terminal is not itself an agent.
- 02ConfigurationUnderstand how that program receives its settings and why different processes can behave differently.
- 03JSON & schemasRead the messages programs exchange. Separate a field's name, type and meaning before following an API request.
- 04APIsMove from a person using a command to one program requesting something from another.
- 05RESTSee how resource addresses, HTTP methods and status codes organize a web API.
- 06SDKsYou are here
- 07TestsDecide what observable behavior to check before trusting a change made by a person or an agent.
- 08GitSeparate editable files, selected snapshots and recorded commits. Match the tested content to the change you hand over.
- 09Claude CodeBring commands, configuration and checks into a bounded coding-assistant task.
Bookmark this page to return to this concept. The number shows your place in the reading route; it is not an assessment result.
A software development kit
What is an SDK?
An SDK is a collection of code and supporting tools that helps you use a platform from a programming language. A model-provider SDK can turn a Python method call into an authenticated HTTP request and parse its response. The SDK is not the model or the remote service.
FDEs integrate models, gateways and business systems. Knowing the underlying contract lets you diagnose failures when an SDK hides details.
UNDERSTAND THE SYSTEM
See one method become an HTTP request
Think of a client SDK like a database driver: it gives your code a way to talk to a service. It does not install that service or its model. Follow the six cases from the downloadable lab; these are explained local observations, not a live model simulation.
Read the connections in plain English
- 01Your application → Client SDK
Pass model, messages and an output allowance to the installed client.
- 02Client SDK → API endpoint
Send POST /v1/messages to the configured local endpoint.
- 03API endpoint → Returned outcome
The endpoint can return a status and body, or leave the client waiting.
- 04Returned outcome → Your application
Application checks distinguish a reviewable draft, a response to inspect and an unknown outcome.
Check your understanding: Which part decides whether HTTP 200 is enough to continue?
The application owns that decision. The client helps exchange the request and response. Check the result required by your workflow; a model, agent loop and usable answer are not implied by installing an SDK.
CONNECT IT TO WHAT YOU KNOW
Start with something familiar.
It is a typed adapter around a service contract, much like a database driver helps your application speak to a database.
A convenient method can still incur network latency, cost and side effects. Inspect retry and timeout behavior rather than treating it as a harmless local function.
Words worth knowing
- Serialization
- Encoding values into a transportable format.
- Timeout
- A limit on how long an operation waits.
- API version
- The contract edition expected by client and service.
Useful foundations
Open a definition and diagram here. Your lesson stays in place.
Data a program can read and checkWhat are JSON and schemas?
QUICK REFERENCE / 101
What are JSON and schemas?
JSON (JavaScript Object Notation) is a text format for exchanging data between programs. An object pairs field names with values, like a small form with named boxes. JSON Schema describes rules for those values. Neither is an AI model, and JSON works with many programming languages.
An API response, an agent's tool arguments and a model's structured answer often arrive as JSON. Before connecting them, an FDE needs to read the fields, recognize their types and explain why readable data can still be wrong for the task.
A software contractWhat is an API?
QUICK REFERENCE / 101
What is an API?
An application programming interface (API) is an agreed way for one piece of software to use another. It specifies operations, inputs, outputs and errors. Some APIs are local functions; a web API exchanges requests and responses across a network.
An agent becomes useful through connections to business systems. Those connections need clear contracts and failure behavior.
Settings supplied to a running programWhat are environment variables and configuration?
QUICK REFERENCE / 101
What are environment variables and configuration?
Configuration is the set of settings an application uses to choose its behavior. An environment variable is a named text value available to a running process, such as an attempt limit. A dotenv file stores settings as name=value lines. The file must be loaded by a runtime, library or framework before its values affect the program.
An FDE moves an application between a laptop, a client environment and deployment. The same code can behave differently because its launch settings differ. Trace where each effective value comes from before changing prompts or reinstalling an SDK.
ONE EXAMPLE / FICTIONAL CASE
Follow the connections.
Your application uses an SDK to ask a model for a draft. A timeout leaves you needing to understand whether the provider processed the request.
UNDERSTAND THE SYSTEM
See one method become an HTTP request
Think of a client SDK like a database driver: it gives your code a way to talk to a service. It does not install that service or its model. Follow the six cases from the downloadable lab; these are explained local observations, not a live model simulation.
See what moves and why.
Read the connections in plain English
- 01Your application → Client SDK
Pass model, messages and an output allowance to the installed client.
- 02Client SDK → API endpoint
Send POST /v1/messages to the configured local endpoint.
- 03API endpoint → Returned outcome
The endpoint can return a status and body, or leave the client waiting.
- 04Returned outcome → Your application
Application checks distinguish a reviewable draft, a response to inspect and an unknown outcome.
Check your understanding: Which part decides whether HTTP 200 is enough to continue?
The application owns that decision. The client helps exchange the request and response. Check the result required by your workflow; a model, agent loop and usable answer are not implied by installing an SDK.
Work through it, step by step.
Configure
Choose the provider endpoint, credentials and supported API version through secure server configuration.
What you have now: A configured client
Call
The SDK serializes your request and sends it over the network. Keep deadlines and retry budgets bounded.
What you have now: A remote operation
Interpret
Read documented response fields, usage and errors. Record metadata rather than secrets or full sensitive prompts.
What you have now: An observable integration
FROM RECOGNITION TO REASONING
Follow a real client call across a local HTTP boundary.
- 01
Compare raw HTTP and the SDK using the free local lab; locate the request and response checks.
- 02
Predict and observe a retry, a 400 error, a timeout and an unexpected response body.
- 03
Change the retry limit and completion reason separately, then explain the resulting decisions.
Six request traces, two controlled changes and an integration card with explicit limits.
Compare your reasoning when you are ready
The SDK prepares transport; the application decides what to accept. A timeout preserves an unknown remote outcome, and HTTP success alone does not establish a usable result. The lab uses a real client and local HTTP with authored responses, not model inference.
Keep notes in your own working copy. Moving through these cards does not record completion.
TURN THE IDEA INTO USEFUL WORK
You can now go deeper.
A convenient method can still incur network latency, cost and side effects. Inspect retry and timeout behavior rather than treating it as a harmless local function.
Academy lessons use your existing training access. Free guides stay open.