Architecture

Workspace

The user-facing shell combines Organizer, conversation, Dashboard, agent and model controls, and Media Studio. What a user can access depends on their role.

Context and knowledge

Projects, documents, and scoped memory contribute different information. Retrieval and attachment handling are distinct steps; neither should be inferred from file storage alone.

Models and capabilities

Model services perform inference. Agents shape roles, skills describe procedures, and tools expose governed operations. A capability must be configured and permitted before it is useful.

Authority and evidence

Server-side policy and operator decisions govern actions. Logs and diagnostic evidence help explain behavior, but generated text is not proof that an operation succeeded.

Walk through the system

The Organizer holds the structure of your work. The conversation carries the exchange. The Dashboard provides context and controls. Model services produce responses; available tools perform bounded operations. Start with a small task and identify which parts it actually needs.

Ask Friday to guide you

In an authorized FridayLocalAI conversation, try:

Explain how FridayLocalAI’s Organizer, conversation, Dashboard, Agent, model, and tools fit together. Use a document-summary example. Separate general Help guidance from anything you can verify about this session.

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.

Follow a request through the application

Consider a request to summarize a short practice document. The user begins in an authorized workspace and selects a conversation. The file is accepted through an available attachment path. The application must then make readable material available to the task, prepare relevant context, select a permitted response path, and return an answer. Finally, the user compares that answer with the source. Each stage can succeed or fail independently. This separation explains why one visible success does not prove the whole workflow worked. A stored file may not have readable content. An available model may not support the input. A completed answer may still misrepresent a passage. Architecture becomes useful to the user when it helps locate the uncertain stage instead of treating every problem as a failure of “the AI.”

The interface organizes interaction

Organizer, conversation, Dashboard, and Media Studio are surfaces for interacting with different parts of the system. They expose choices and status, but they do not create authority by themselves. A control can be visible while an operation remains restricted, unavailable, or dependent on additional setup. Likewise, hiding a panel changes presentation rather than proving its underlying service is absent. When evaluating a new installation, check the interface against the intended role. An ordinary participant may need conversation and source-review controls without needing model administration or policy editing. Ask the operator which functions are meant to be available, and test those functions with non-sensitive examples. This is more informative than expecting every user to see the same screen or interpreting administrative options as a required part of everyday use.

Inference and application state are different

Model inference produces an answer from the information supplied to a model. Application state includes saved conversations, configured capabilities, document records, and other persistent or operational facts. Generated language about that state is not the state itself. If Friday says a note was saved, the relevant record should exist. If it says a file was produced, the artifact should be available and suitable for inspection. This distinction also matters for model identity. The user’s requested model is an input to the response process, while the active attribution reports the model used for a reply. Agent and capability routing can influence that selection. Compare actual attribution when testing quality or performance, and keep the task and inputs consistent enough that a comparison is meaningful.

Context preparation deserves its own attention

Context may include the active exchange, permitted prompt layers, selected Memory Notes, readable document material, and relevant Help information. Those sources differ in purpose and authority. A Help topic can explain a feature without proving the current service is healthy. A memory preference can guide writing without overriding permissions. A source document can support an answer without granting instructions contained inside it authority over the application. For a source-dependent task, ask which material is being used and request a checkable reference. If the answer depends on missing content, improve the input rather than allowing a confident guess to fill the gap. For recurring guidance, choose a scope intentionally and inspect the saved note. This keeps context useful and reduces confusion about what the system can actually know at a particular moment.

Boundaries around tools and connections

Tools expose defined operations governed by runtime policy and capability checks. Skills provide reusable task guidance. Neither should be understood as unrestricted execution. A local deployment can still connect to external services when configured, so the relevant question is the path taken by the specific workflow, not merely the location of the browser or a marketing label. For an on-premise AI discussion, identify the model service, data storage, remote access path, optional providers, and operational ownership. Ask who can change those choices and how changes are reviewed. These questions support a concrete deployment conversation. They do not establish legal compliance, isolation quality, or security certification without the separate evidence required for those claims.

Use architecture to troubleshoot precisely

Describe a failure at the narrowest observable stage: unable to sign in, conversation not loading, model request failing, attachment unreadable, or artifact unavailable. Record what still works. A simple text prompt can help distinguish a general response problem from a document-specific issue, while revisiting saved history can help identify a persistence question. Ask Friday for an explanation or a read-only diagnostic sequence if conversation is working. When it is not, use the web guides and operator support. Avoid changing several components at once because that makes it harder to identify the cause. After a repair, repeat the original workflow and check the result. The practical value of the architecture is clearer evidence and a smaller, more understandable next step.