> For the complete documentation index, see [llms.txt](https://docs.lleverage.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.lleverage.ai/run-operations/agent/getting-started.md). # Getting started with the Agent Run a useful first task with the Agent and learn the operating pattern you can reuse for later work. The fastest way to understand the Agent is to give it a real piece of work whose result you can judge. Do not start with a generic “what can you do?” prompt. Start with a bounded operational outcome. Your Project Agent page may already show starter cards for common work. Choose one when it matches the job, or start your own session. Starter cards are examples and entry points, not limits on what the Agent can do. ## 1. Pick a task with a checkable result Good first tasks have accessible evidence and a clear finish line. For example: * “Compare this supplier confirmation with the open purchase order and show me the differences.” * “Check why order 4831 is blocked and tell me what is missing.” * “Read these certificates and return only the exceptions.” * “Use the current ERP and planning data to explain where this week's production plan is at risk.” Avoid making the first attempt an irreversible or high-risk action whose effect you cannot easily verify. ## 2. Give the outcome, not a script A useful request normally gives the Agent four things: * **Outcome** — what should be true when the work is finished. * **Relevant evidence** — files, systems, records or context it should use. * **Constraints** — what it may not assume or change. * **Result** — what you want back so you can judge the work. For example: > Compare the attached supplier confirmation with PO 10483 in the ERP. Treat the ERP quantities and item numbers as authoritative. Do not change the order. Return the mismatches and cite the evidence you used. You usually do not need to prescribe every intermediate step. ## 3. Let it work through the evidence The centre of the session shows the conversation and visible activity around the run. For longer or more important work, also use the session workspace: * **Progress** — is the current task still running? * **Files** — what concrete outputs were created? * **Context** — which tools or referenced material contributed? * **Memory** — did persistent context contribute to the work? See [Session workspace](/run-operations/agent/session-workspace.md). ## 4. Answer only the questions that matter The Agent may pause when information, judgement or approval is genuinely required. Answer in the same session when the question belongs to the current task. If the Agent asks for something it should already know every time, that is a setup problem to fix later rather than a prompt operators should keep repeating. ## 5. Check the actual result Do not judge only the final prose. Check the strongest available evidence: 1. the actual business-system result or post-condition; 2. the files, records or calculations produced; 3. the visible activity and source material used; 4. Monitoring or Activity evidence where deeper inspection is needed. A confident answer reached from the wrong source is still a bad operational result. ## 6. Correct the cause If the result is wrong, identify the layer that caused it: * missing one-off information → correct this session; * wrong recurring method → improve the Skill; * stale structured reference → update the Table or source data; * weak maintained guidance → update Knowledge; * wrong persistent context → correct Memory; * missing system authority → fix the Connection; * stable sequence needs tighter control → move that part into a Workflow. The aim is to improve the operating setup, not to invent an increasingly elaborate prompt. ## 7. Leave feedback when the outcome was good or bad Agent sessions support persistent outcome feedback, so the people improving the Agent can inspect what worked and what did not alongside the execution evidence. For a recurring issue, give enough detail to reproduce it: what was wrong, where it appeared, what source should have been used and what you expected instead. ## 8. Turn repeated work into a Skill When the same task and corrections recur, ask the Agent to turn the method into a Skill. A builder can review the proposed Skill, run representative tests, correct it and publish deliberately. The live Skill does not silently rewrite itself just because one conversation went badly. See [Using Skills](/run-operations/agent/agent-context/skills/using-skills.md). ## What success looks like A strong first milestone is not “the Agent can answer anything.” It is: **the Agent can complete one useful operational job, use the right evidence, make uncertainty visible and stop reliably where a person still needs to decide.** ## If you cannot start a session First confirm that you have access to the Project. In organisations where usage-based Agent access is enabled, ordinary organisation membership and direct Agent access can also be separate. You may need an Agent seat, and a configured usage limit can pause new Agent messages when that boundary is reached. Where the request flow is enabled, members can request an Agent seat or a higher limit and an organisation Owner can approve it. See [Subscription Management](/administer-and-govern/control/settings/subscription-management.md) for the current seat and usage-limit model. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.lleverage.ai/run-operations/agent/getting-started.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.