Documentation

Getting started

Review installation prerequisites, then work through the first-run checklist with an authorized account.

Configuration

Understand model selection, memory scope, storage, role boundaries, and optional integrations.

Agents and capabilities

Learn how agents, skills, and tools fit together without confusing a role with permission to act.

Knowledge and troubleshooting

Check document readability and context, then use a focused diagnostic workflow when something fails.

Use the guides with Friday

Begin with the first-run checklist and a simple conversation. Progress to documents, model selection, memory, and tools only as needed. Each guide includes an example question you can paste into Friday. Work in the authorized deployment supplied by your operator; the public website is documentation, not the application workspace.

Ask Friday to guide you

In an authorized FridayLocalAI conversation, try:

Help me choose the right FridayLocalAI guide for my task. Ask whether I need first-run help, a conversation, document review, model selection, memory, or troubleshooting. Give one next step and explain what success should look like.

Tell Friday what you can see and which step you have reached. If the instructions do not match your screen, say so; ask for the relevant Help topic or contact your operator. Friday cannot be assumed to see your screen or know your current settings.

Consumer guides

Download the consumer guides from Document Manager’s public document catalog. The Quick Start covers a first practice session; the User Guide collects the application walkthroughs and example prompts.

Consumer document downloads

Find the guide that matches your starting point

Documentation is most useful when it answers the question you have now. If you have not received access, start with Early Access and Installation. If you can sign in but are unfamiliar with the interface, begin with the first-run checklist. If basic conversation works, choose the guide for documents, model selection, memory, or another capability relevant to your task. You do not need to read every technical page before trying a harmless practice exchange. Start small, learn the controls involved, and expand only when the next capability is needed. The architecture and governance pages explain why the application distinguishes context, models, permissions, and completed actions. Return to those explanations when a workflow raises a question that a simple sequence of clicks cannot answer.

Read the website and application together

The website provides a stable place to read about the product, while the application supplies the controls and state for your actual work. Treat those as complementary sources. A guide can describe where to look, but your role and release determine the controls you can use. If the screen differs, identify the difference instead of forcing the instructions to fit. Ask Friday to explain the step using the relevant built-in Help where available. Tell it the labels you can see and what you expected to happen. It should not be assumed to observe your screen automatically. When guidance conflicts with a verified result or the operator’s instructions, stop and resolve the discrepancy. A useful documentation workflow leaves you with a clearer understanding rather than an unsupported claim that everything should be available.

Follow the learning sequence

First verify access, a completed response, and saved conversation history. Next practice prompting with a goal, context, constraints, and an output format. Then learn source handling with a small text attachment whose contents you can check. These steps build on one another and help you recognize which part of a more complex workflow is uncertain. After that, explore model attribution and Memory Notes. Understand the difference between requesting a model and observing the model used, and between drafting a preference and saving a scoped note. Skills & Tools and Media Studio can come later when your task requires them. A staged learning sequence is easier to diagnose than trying every feature during the first session and being unable to identify what caused a failure.

Treat examples as practice material

The prompts in these guides are starting points. Replace bracketed details with your own non-sensitive task description and adapt the request to your goals. An example does not grant permission to access a file, change a setting, or contact an external destination. It also does not promise that every required capability is configured for your account. Use fictional notes or a short permitted excerpt while learning. Define what success should look like before sending the request. If an answer contains an invented detail, correct it and examine the revision. If an operation is unavailable, ask which boundary applies rather than requesting a workaround. The point of practice is to develop judgment about the result as well as familiarity with the interface.

Keep a record of important differences

If your installation behaves differently from a guide, record the feature, visible label, expected result, and observed result. Include the time and the Agent or model information when relevant. A concise report helps distinguish outdated wording, a role difference, a configuration issue, and an actual regression. Avoid sending raw logs or private material through a public contact channel. The operator may have release-specific instructions that are more precise for your environment. Keep those instructions available and note which deployment they apply to. Do not merge guidance from several installations into one assumed procedure. In particular, installation commands, storage paths, and provider settings should come from the supported deployment process, not from an unrelated example or a model’s attempt to fill in missing details.

Use consumer documents as a companion

The Quick Start and User Guide are available through the website’s Document Manager catalog. They collect practical guidance for reading away from the live page and for keeping a reference handy. They are consumer documents, not a software package, public installer, or guarantee that all described controls are enabled in every environment. Check the document’s version or date when comparing it with the website. Use the web pages for navigation to related topics and the application for actual controls and results. If conversation is unavailable, the written guide can still help you prepare a useful support report. If you are exploring whether the product fits your work, contact the project about early access; the documentation does not require a store purchase or a third-party book purchase.