Cron Scheduled Ollama Autonomous Agent

This week’s focus on benchmarking large language model (LLM) inference at scale has sparked renewed interest in how we can build autonomous agents that operate efficiently and responsibly on the edge. As we explore the intersection of on-device AI and autonomous systems, we’re seeing new patterns emerge in how we manage inference pipelines, especially when dealing with real-world constraints like latency, accuracy, and user safety.

At Apex Grid, we’ve been building a cron-scheduled autonomous agent using Ollama as the core inference engine. This agent is designed to operate on a periodic basis, generating and publishing content across multiple social channels. The system is structured with a clear separation of concerns, ensuring that each component - voice profiling, controversy checking, credit verification, and content quarantine - can be independently tested, scaled, and maintained.

The agent operates on a strict pipeline: first, it generates a voice profile from a user’s input, stored as a separate JSON file. This profile is used to personalize the output. Then, the generated content passes through a “controversy gate” - a second model that acts as a filter, scanning for potentially harmful or controversial content. Only after passing this gate does the content proceed to the “credit gate,” which performs a real-time probe against a Postgres database managed by Postiz. This step ensures that the agent only publishes content from verified users. If the content fails any of these checks, it is moved to a quarantine folder for later review or deletion.

Here’s what the publish_to_all_channels function looks like in our implementation:

from ollama import Client
import json
import os
import psycopg2
from datetime import datetime

def publish_to_all_channels(content, voice_profile_path):
    # Step 1: Load voice profile
    with open(voice_profile_path, 'r') as f:
        voice_profile = json.load(f)

    # Step 2: Controversy gate check
    controversy_model = Client(host='controversy-gate-model-endpoint')
    controversy_check = controversy_model.generate("Is this content controversial?", content)
    if controversy_check['response'].lower() in ['yes', 'maybe']:
        move_to_quarantine(content, voice_profile)
        return False

    # Step 3: Credit gate check
    try:
        conn = psycopg2.connect(
            dbname="postiz_db",
            user="user",
            password="password",
            host="postiz-db-endpoint"
        )
        cur = conn.cursor()
        cur.execute("SELECT verified FROM users WHERE content_hash = %s", (hash(content),))
        result = cur.fetchone()
        if not result or not result[0]:
            move_to_quarantine(content, voice_profile)
            return False
    except Exception as e:
        print(f"Credit gate error: {e}")
        move_to_quarantine(content, voice_profile)
        return False
    finally:
        if conn:
            conn.close()

    # Step 4: Publish content
    for channel in ["twitter", "telegram", "mastodon"]:
        publish_to_channel(channel, content, voice_profile)
    return True

This approach allows us to decouple the inference logic from the publishing logic, making the system more robust and easier to maintain. However, it’s not without tradeoffs. The use of a second model for controversy checking increases inference latency and cost. Additionally, the reliance on a Postgres probe for credit verification introduces a single point of failure if the database is unreachable or slow.

We’re actively exploring ways to reduce this latency by integrating lightweight on-device filtering models and implementing fallback strategies for database connectivity. We’re also evaluating whether we can replace the second model with a rule-based system for certain types of content, which could reduce both cost and complexity.

What we’re building next is a more distributed version of this agent, where each gate can be independently scaled and deployed across multiple nodes. We’re also looking into using a hybrid approach - combining rule-based checks for low-risk content with model-based checks for high-risk scenarios. We’d love to hear from the community: have you seen similar patterns in your autonomous agent pipelines, or have you found better ways to handle multi-model inference in production?