We built a cron-scheduled autonomous agent that runs on Ollama, manages voice profiles as separate files, and includes a controversy gate and credit gate before publishing to social channels. This agent is designed to be both safe and expressive, and we'll show you exactly how it works.
Our stack runs on a combination of Ollama for LLM inference, Postgres for data storage, and a custom Python script that ties it all together. The agent is scheduled to run every hour using cron, and it processes a queue of voice messages that have been generated by other systems. Each message is checked against a controversy gate and a credit gate before being published to all social channels.
The controversy gate is implemented using a second model that acts as a classifier. It checks if the content might be controversial or harmful. If it is, the message is moved to a quarantine folder for review. The credit gate checks if the user has enough credits in the Postiz DB to publish the message. If they do, the message is published to all channels; if not, it's also moved to quarantine.
Here’s how the publish_to_all_channels function is structured in our codebase:
def publish_to_all_channels(message_id: str, voice_profile: str, content: str) -> bool:
# Load the message from the queue
message = load_message_from_queue(message_id)
# Check voice profile
if not is_valid_voice_profile(voice_profile):
log(f"Invalid voice profile for message {message_id}")
move_to_quarantine(message_id)
return False
# Controversy gate: check with second model
if is_controversial(content):
log(f"Controversial content detected for message {message_id}")
move_to_quarantine(message_id)
return False
# Credit gate: check Postiz DB
if not has_sufficient_credits(message.user_id):
log(f"Insufficient credits for user {message.user_id}")
move_to_quarantine(message_id)
return False
# Publish to all channels
publish_to_twitter(content)
publish_to_telegram(content)
publish_to_mastodon(content)
log(f"Published message {message_id} successfully")
return True
This function runs in the order of voice profile validation, controversy gate, and credit gate. Each step is a critical check that ensures the message is both safe and authorized before being sent out. The quarantine folder is a key part of our system - it allows us to review and potentially reprocess messages that fail any of the gates.
One of the key tradeoffs we made was the use of a second model for the controversy gate. While it adds computational overhead, it significantly improves the safety of the system. We also chose to store voice profiles as separate files rather than embedding them in the message structure, which made it easier to manage and update them independently.
We’re currently working on integrating a real-time feedback loop that allows users to flag messages that should be quarantined or republished. We’re also exploring ways to reduce the latency of the controversy gate by using a lightweight model that can run on the edge. What do you think about using a lightweight model for real-time filtering?
Top comments (0)