Quickstart

Just install and ask your agent

The shortest path is to install the CLI and hand the task to your LLM. The agent reads the docs registry, picks the matching flow, runs the bounded commands, and reports back. You answer occasional questions; the agent does the setup.

curl -fsSL https://app.pipelogic.ai/api/v1/install | bashCopy
ppl login                # or `ppl register` for a new accountCopy
ppl mode general         # put the shell into the starter agent profileCopy

Then give your LLM a one-line task:

That is the whole onboarding. The agent runs component lookup, backend assembly, parameter binding, fixture runs, deployments, and proof. It stops at promotion and destructive overwrites, and reports those to you for a human decision.

To drive it yourself, read on. The rest of this page covers the manual path.

TL;DR

• Pipelogic is an agent-native AI platform: every primitive — components, backends, deployments, applications — is reachable from one CLI built so that an LLM can drive it as readily as a human can.
• The unit of code is the component: typed, versioned, containerized. The unit of composition is the backend: a checked graph that pins component releases and binds them into one workflow. The unit of runtime is the deployment.
• The platform models AI composition as first-class primitives — typed streams, pinned releases, checked graphs, event-sourced backend mutations, separated deployments — so that the work of composing inference steps is handled by the platform rather than by per-project glue code.
• Quickstart starts from wherever you are: writing code, assembling existing components, integrating a trained model, automating a data pipeline, proving behavior before promotion, running production, or binding a UI.
• Whichever path you pick, the loop is the same: pin code → bind into a graph → run the graph → collect evidence → decide.

What the platform is

Pipelogic is a platform that models the full AI composition surface — chaining inference steps, marshalling typed payloads, versioning models, sharing capabilities, and proving behavior across versions — as first-class objects rather than as per-project glue code.

The primitives map directly onto those concerns:

• Components wrap the runnable unit (a Python or C++ codebase plus its containerization). Each release is immutable and addressable; backends pin a specific release.
• Typed streams between components are checked at graph-edit time, before deployment. Connecting an Image output to a [BoundingBox] input fails immediately, with a precise type error, instead of at runtime inside a container.
• Backends are an event-sourced graph: every change (add-vertex, connect, change-parameter, add-file, change-endpoint-alias) is an operation with an inverse, so the whole graph is undoable, reproducible, and inspectable.
• Deployments decouple "graph definition" from "live runtime". The same backend can be redeployed on different runtimes (managed cloud, your own hardware) without rewriting anything.
• Applications bind a product UI to deployed backend endpoints when the solution needs a human-facing surface.

The CLI (ppl) is the first-class control surface for all of this. It is built for LLM-driven workflows from the start: machine-readable output, agent profiles that scope what the model can see and run, and destructive operations gated at the command boundary. A human can drive it the same way; the App at app.pipelogic.ai is a visual surface over the same primitives.

One set of primitives, many entry points

Every entry point — assembling from the catalog, bringing your own components, binding your own trained models, running on managed cloud or your own enrolled hardware, driving from an LLM or a browser — lands on the same primitives, with no rewrite to move between them.

The surrounding machinery is shared across those entry points: direct integrations to common hubs and registries, type checking when components compose, capacity checks when deployments land, and cleanup when leases close. Each is part of the platform so that it does not have to be rebuilt per project.

Mental model

component.yml + src/
        │
        ▼
   component
   prerelease  ──promote──▶  released version
        │
        ▼
   backend graph ──deploy──▶ deployment ──▶ proof + (optional) application
   (vertices,
    bindings,
    endpoints)

Reading the diagram bottom to top: a deployment is one running instance of a backend graph on a runtime; the graph itself is a typed composition of pinned component releases; releases come from component source code plus a component.yml manifest that declares what the component consumes, produces, and configures.

A complete solution is the deployed backend, the evidence that it behaves as expected, and (when the product needs it) an application bound to its endpoints. Everything else is supporting machinery.

New to the platform? Read Components and Backends first.

Why a CLI-first, agent-native surface

The CLI is the primary surface because it gives the platform precise control over two things that matter for LLM-driven workflows: context size and safety at the command boundary. One command runs one bounded operation, returns one compact result, and the next command is chosen from that result. There is no big up-front tool registry to load, no fan-out of intermediate state through the model.

Agent profiles are a real execution surface, not a formatting flag. Switching the shell into an agent profile changes which commands are visible, locks the surface against destructive operations, switches output to machine-readable shapes, and prevents the session from silently escaping back to a human surface. The same ppl binary serves human users and LLM agents; the profile is what differs.

Set the shell into the broad starter profile and let your LLM drive:

ppl mode generalCopy

After mode, commands stay plain ppl …; the profile is sticky for the session. A per-command override is also available for one-off calls without changing the saved session.

The docs registry is the agent's map of the platform: discover the available docs as a tree, search when the branch is unclear, fetch the exact flow, then execute the next bounded command. The agent does not need a separate concept of "what flows exist" — it asks the registry.

ppl docs treeCopy
ppl docs search <query>Copy
ppl docs get flows/quickstartCopy

MCP integration is being added for editor workflows, but it builds on the same ppl command and docs surface rather than replacing it. The CLI stays the load-bearing path so the default LLM workflow remains lean and deterministic.

Install and sign in

curl -fsSL https://app.pipelogic.ai/api/v1/install | bashCopy
ppl register      # new accountCopy
ppl login         # existing account (browser flow)Copy
ppl login --console   # terminal credentials when browser is unavailableCopy

Pick your starting point

Every quickstart path lands in the same loop — pin code, bind into a graph, run the graph, collect evidence — but each starts from a different artifact you already have.

Build a component

Use this path when the unit of work is new code: a Python or C++ implementation of a capability that does not yet exist in the catalog, or that you want to own as a reusable building block.

A component is more than "a function packaged as a container". It is a typed contract: declared input and output stream types, declared configuration schema, optional declared model file slots, optional declared service dependencies. The typed contract is what the backend graph relies on at composition time, and what makes the same component reusable across many backends without re-explaining what it does.

The author loop is intentionally short: scaffold the codebase, write the implementation against the typed inputs and outputs, publish a prerelease (the platform builds and registers it), then test the prerelease inside a live backend before promoting it. Promotion to the released catalog is a separate, deliberate decision — it is the public commitment that the version is stable.

Walkthrough and language-specific authoring detail: Test with a live backend, Release semantics, and the Component API reference.

Assemble a backend from existing components

Use this path when the catalog already holds the building blocks and the work is composition: pick the right components, wire their typed streams together, bind parameters and files, and expose the endpoints the caller or application will use.

Backend assembly is event-sourced graph editing: every change is an operation with an inverse, the whole graph is reproducible from its operation log, type inference re-runs on every edit so mismatches surface immediately, and the same edits run unchanged in the App and through the CLI.

Backends compose; components do not. A given component might appear as multiple vertices in the same backend with different parameter bindings and different downstream consumers. That separation is the reason a single capability can power many solutions without forking the code.

Walkthrough: Backend operations and Test with a live backend.

Integrate a trained model

Use this path when the input is a model artifact: weights, checkpoint, ONNX file, adapter, or a model repository, and the work is "turn it into a serving capability inside a backend".

Pipelogic separates "model serving infrastructure" from "model artifact" deliberately. Serving runtimes — Triton, TorchServe, Ollama, vLLM, SGLang — are platform-managed services. A component declares which serving service it depends on, and the platform stands the service up alongside the component containers when the backend deploys. You do not run Triton; you point at it.

The artifact itself is uploaded as a typed file, then bound into a component vertex's file slot. That binding is part of the backend graph: it is reproducible, it is undoable, and swapping the artifact for a new version is a single graph mutation rather than a redeploy of the underlying serving service. The same model can be bound into multiple backends; different model versions can be A/B'd inside a single backend by binding both into sibling vertices.

The hard work in this path is rarely "upload the file". It is fast iteration: change the artifact, run representative fixtures, compare outputs, measure cold-start and steady-state latency, check failure modes (out-of-memory, wrong tokenizer, wrong image size, wrong label set), and decide whether the artifact is ready for promotion.

Walkthrough: Model artifact integration and Models.

Automate a data pipeline

Use this path when the input is data — CSV, images, audio, JSON, parquet, or any repeatable input set — and the work is "process it through a backend, on a schedule or on demand, in a way that's reproducible next quarter".

A backend is a real-time graph by default: it consumes its inputs as typed streams and emits outputs as typed streams. That is exactly what an "automated data pipeline" needs. The same backend can run as a one-off fixture, as a scheduled batch over a directory of inputs, or as a long-lived stream consumer; the graph does not change, only the input source does.

Treating data pipelines as backends — not as bespoke ETL scripts — buys you the same guarantees the rest of the platform gives: type checking before deployment, reproducible runs across versions, swappable component releases, separable runtimes. Yesterday's pipeline still produces yesterday's output, because the backend is pinned end-to-end.

Walkthrough: Data pipeline automation and File upload and binding.

Prove behavior before promotion

Use this path when something is about to ship — a new component version, a new model artifact, a new backend revision — and the work is "produce reproducible evidence that it does what it claims, on the inputs that matter".

Proof is treated as a first-class loop, not an afterthought. The mental shape is the same as a test in any other engineering discipline: identify the exact unit under test, freeze the fixtures, run them through the runtime, collect outputs and runtime signals, compare against expectations, keep the artifacts. Pipelogic gives you the primitives — pinned versions, deterministic graphs, capturable outputs, container logs — and stays out of the business of declaring what "passes".

Proof needs its own loop because a single passing example is not evidence. Real proof is fixture coverage, runtime-signal capture, semantic comparison, and a record that can be replayed against the next candidate version, so that a promotion decision rests on observed behavior rather than on a guess.

Walkthrough: Prove behavior.

Deploy, monitor, and debug

Use this path when the graph is already clean and the work is operating it: deploy to a runtime, watch the running containers, debug when something misbehaves, redeploy on a version bump, tear down when finished.

Deployment is intentionally separate from graph editing. The backend is a checked definition; the deployment is one running instance of that definition on one runtime. The same backend can be deployed multiple times in different environments by forking the backend first — the link between a backend and its deployment is 1:1, and that constraint is what makes "what is currently running" unambiguous.

Once deployed, the runtime view shifts from "the graph" to "the containers": each vertex becomes one or more component containers on the runtime, each edge becomes platform transport between them. Debugging is container-level — container logs are the source of truth for what a component is doing — and the platform exposes the same vertex / endpoint / runtime mapping that the graph had.

Walkthrough: Deploy and monitor and Deployments. Failure lookup: Common failures.

Bind an application to a backend

Use this path when the solution needs a product UI in addition to the backend graph.

A application in Pipelogic is a managed surface declared by a manifest. Each entry in the manifest's needs array declares a named endpoint the UI requires: its role, its direction (ingress or egress), the transports it speaks (http, ws, sse, or webrtc), and whether it is required. The manifest is bound to a deployed backend so that endpoint URLs resolve consistently and so that breaking the binding — deploying an incompatible backend revision — surfaces as an application error rather than as a silent failed request.

Application creation is currently a private alpha surface — the command group appears only in workspaces where it has been enabled. When available, the loop is: declare the manifest, build or upload the UI image, deploy the application, verify the URL, iterate.

See Applications and Deploy and monitor.

Where the loop ends

Every path lands at the same checkpoint: a fixture went in, an output came back, the runtime state was inspected, and an unambiguous decision is available — promote, redeploy, fork, tear down, or hand back to a human. Typed graphs, immutable releases, separated deployments, and proof loops are what make that decision rest on attached evidence rather than on inference about whether the feature worked.

Related

• Components — what a component actually is and how releases work.
• Backends — typed graphs and the event-sourced operation log.
• Types — the contracts backend connections validate.
• Deployments — runtime model for a backend on a runtime.
• Guides — suggested reading order by task.
• Deploy and monitor — checked backend to live traffic.