Truss guides
Clear explanations of local models, BYOK providers, permissions, and the workflows that let you use an agent without giving up your tools or your workspace.
A practical guide to choosing a coding agent you control: local models when privacy and offline work matter, your own provider account when capability matters, and a single runtime across every workspace.
Read the guideTurn an Ollama model into a useful local coding agent without confusing a model server for an agent workflow.
Read the guidePrivate code needs more than a local model checkbox. Build a workflow around visible context, controlled tools, and an intentional cloud fallback.
Read the guideUse the model provider account you already trust, keep keys out of repositories, and make provider failures understandable.
Read the guideA practical VS Code workflow for developers who want a local model or their own API provider—not a locked-in assistant plan.
Read the guideUse a coding agent from the shell without trading away the terminal, Git, or local models that make your workflow yours.
Read the guideThe useful safety boundary is not ‘always allow’ or ‘never allow.’ It is choosing the smallest capability that fits the current task.
Read the guideMCP can extend a coding agent beyond files and terminal commands. The important part is choosing and governing every added tool.
Read the guideA Linux-first coding-agent setup that starts simple, works in the terminal, and can grow into desktop or editor workflows without replacing your tools.
Read the guideThe best coding agent is not the one with the loudest demo. It is the one that fits your model, workspace, permission, and review requirements.
Read the guideBetter agent results come from relevant context and a clear task—not from pasting the entire repository into a chat box.
Read the guideA model can answer questions. An agent harness gives it a controlled way to understand a workspace, use tools, and recover from real work.
Read the guideYour editor is where you work. A coding-agent runtime is the layer that makes agent behavior, tools, and safety policies portable.
Read the guideTool calling is how an agent stops guessing about a repository and starts gathering evidence, under rules you can inspect.
Read the guideIf you cannot see an agent's context, tool activity, and result, you cannot confidently debug or review its work.
Read the guideA useful coding-agent evaluation measures how it works in a repository, not whether it can produce one plausible snippet.
Read the guideA persistent agent session should preserve useful workspace state, not force you to repeat the task every time an editor closes.
Read the guideParallel agents help when tasks are independent and reviewable. They hurt when every agent changes the same files without a clear owner.
Read the guideProvider flexibility is not about chasing every model. It is about keeping one workflow when a model, account, price, or policy changes.
Read the guideSafe coding-agent automation is not about removing tools. It is about making powerful tools explicit, scoped, and reviewable.
Read the guideAgentic development works best as a repeatable engineering loop: inspect, plan, act with boundaries, review, and verify.
Read the guideA useful provider choice starts with the job, the repository boundary, and a real connection test, not a leaderboard screenshot.
Read the guideThe right agent harness depends less on a single model and more on where you work, how tools are controlled, and how portable the workflow needs to be.
Read the guideTool reliability is an engineering problem: make requests structured, failures specific, and the next recovery step obvious.
Read the guideMore context is not automatically better. A context strategy chooses the smallest reliable evidence set for the current engineering decision.
Read the guideBYOK should give you provider control, not put a long-lived API key into a repository or a chat transcript.
Read the guide