Tie Archon into local-ai-packaged

Archon
1

I know there are several other messages with discussions of similar topics, but I thought we needed one that really focused on the matter at hand. Cole has mentioned several times that he wants to include Archon but he is juggling a lot of issues, so perhaps we can work together.

There are two approaches.
The first is to create Archon as a separate docker container and just reference all the local-ai-packaged. Then we need to get from one docker network to another.
The second is to actually put Archon into the docker compose for local-ai-packaged. That way we just need to hit services by name.

For the llm, it would be ollama:11434 or localhost:11434. FYI, when running ollama, if you have some giant model loaded and you need to use nomic-embed-text, it appears to load it and run it in computer memory, and leaves your large model loaded and undisturbed.

Regarding the database, for either method I think it would be through pooler:5432 or localhost:5432. But in the package we have the faster dedicated vector database, so would that be a better choice?

Aside from the .env connections, everything else should be set with the stand-alone docker container, but the mods for adding it to the larger local-ai seem to be explained in the “containerizing our local python agent” section of the Ultimate Guide to Local AI… video.

If you have done any of this work already, please respond with what worked for you. I forked the local-ai-packaged on git under local-ai-packaged and will be updating the files there as I work through this problem.

Please join me in this effort or follow along, and I will also be documenting the bits and pieces so as to add anything else to to the amazing local-ai-packaged. – Bob O

2

Inauspicious start.
http://host.docker.internal:8000 worked well enough to continue with setup. Unfortunately, nothing was recorded to the database

Tried the same with :5432 and nothing recorded.

Next step is to try writing to the database with curl and see if either work, and check for errors in the docker log.

No errors at all in the docker log and nothing in the Agent Service log because the service never really started.
The docker container does not have the CURL command available so I used a CLI on the host machine. This required changing the URL to localhost:8000 so the command below wrote a line of dummy info to the dp without error. The correct local supabase URL in the local-ai stack appears to be http://host.docker.internal:8000/rest/v1/site_pages

curl -X POST http://localhost:8000/rest/v1/site_pages -H “apikey: ey…DQ” -H “Authorization: Bearer ey…DQ” -H “Content-Type: application/json” -H “Prefer: return=minimal” -d “{"url":"https://example.com/dummy\",\“chunk_number\”:1,\“title\”:\"Test Page","summary":"This is a test summary","content":"Lorem ipsum dolor sit amet","metadata":{"test":true,"category":"dummy"}}”

3

OK, first Alpine linux is the pits (no CURL command, no api command to install curl), second Cole’s build for the containers is lightning fast, so I just inserted a file called py_test_supa.py and it wrote to the database.

Now to figure out why Archon cannot write to the database but the archon-container can.

import os
from supabase import create_client, Client

# Replace with your Supabase project URL and public API key
# It's recommended to store these in environment variables for security
SUPABASE_URL = "http://host.docker.internal:8000"
SUPABASE_KEY = "ey...DQ"

try:
    # Initialize the Supabase client
    supabase: Client = create_client(SUPABASE_URL, SUPABASE_KEY)

    # Attempt a simple query to verify connection
    # For example, fetching a limited number of rows from a public table
    # Replace 'your_table_name' with an actual table in your database
    response = supabase.from_('site_pages').select('*').limit(1).execute()

    if response.data is not None:
        print("Successfully connected to Supabase and performed a query.")
        print(f"Data retrieved (first row): {response.data}")
    else:
        print("Connected to Supabase, but no data returned from the query.")

    print("\n--- Attempting to insert a new row ---")

    # Data to be inserted
    new_data = {
        "url": "https://example.com/dummy",
        "chunk_number": 1,
        "title": "Test Page",
        "summary": "This is a test summary",
        "content": "Lorem ipsum dolor sit amet",
        "metadata": {"test": True, "category": "dummy"}
    }

    # Perform the insert operation
    # The 'execute()' method implicitly uses 'return=representation' by default,
    # which is similar to what curl does if not specified.
    # To explicitly replicate 'Prefer: return=minimal', you can add .insert(new_data, {'returning': 'minimal'})
    insert_response = supabase.from_('site_pages').insert(new_data).execute()

    # Check for errors during insertion
    if insert_response.data:
        print("Successfully inserted a new row.")
        print(f"Inserted data (if returned): {insert_response.data}")
    else:
        print(f"Error inserting data: {insert_response.count}, {insert_response.data}, {insert_response.error}")

except Exception as e:
    print(f"Failed to connect to Supabase or perform a query: {e}")

I tried to use the chat for a simple question, and it errors out and crashes streamlit. I confirmed the connection to the ollama container with another scripts, py_test_ollama.py

import requests

# Test connection to Ollama API
url = "http://host.docker.internal:11434/api/generate"
headers = {"Content-Type": "application/json"}
data = {"model": "qwen3:14b", "prompt": "Hello!"}

try:
    response = requests.post(url, headers=headers, json=data, timeout=5)
    print("Status Code:", response.status_code)
    print("Response:", response.text)
except requests.exceptions.RequestException as e:
    print("Connection Error:", e)

Unlike supabase, the program is NOT adding the v1 to the endpoint, so the correct address for ollama is http://host.docker.internal:11434/v1

4

OK, I think I made pretty good progress, but still not functional with the local ai. Calling in the big guns @ColeMedin

Any ideas where I go next? env variables are saving properly, the addresses are correct, and the error is somewhere in the requests.

Should the chat work without loading the documentation?

The UI just says the app encountered an error and to check logs.

Logs show two agents did try to query ollama, both failed.

23:51:08.876 reasoner run prompt=
User AI Agent Request: Can you access the LLM?
C...o creating this agent for the user in the scope document.
23:51:08.877 preparing model and tools run_step=1
23:51:08.877 model request
INFO:openai._base_client:Retrying request to /chat/completions in 0.429079 seconds
23:51:08.884 advisor_agent run prompt=Can you access the LLM?
23:51:08.886 preparing model and tools run_step=1
23:51:08.887 model request
INFO:openai._base_client:Retrying request to /chat/completions in 0.477094 seconds

Suggestions?