A realtor approached us with a pretty straightforward request:

They wanted an AI agent that could help run their Facebook page.

The workflow they described was simple:

• they send listing details to the agent,
• the agent turns it into a Facebook post,
• the post gets scheduled automatically,
• and they receive updates through Telegram.

Before deploying it to them, we decided to run the same setup on our own business page first.

For the last 10 days, our own Facebook marketing has been handled through the exact workflow we're preparing for the realtor:

• we feed the system content briefs,
• the agent drafts posts in our page voice,
• scheduled jobs publish throughout the day,
• and every action routes back through Telegram for approval.

The reason we did this was simple:

If we wouldn't trust the system on our own page, we shouldn't ask a client to trust it on theirs.

What ended up being useful wasn't just proving the workflow worked, it was seeing what broke once the system started operating continuously.

A few examples:

At one point the audit system incorrectly marked a publishing session as incomplete even though the Facebook post had already gone live successfully.

Another issue came from Facebook itself, we spent part of the first few days dealing with Meta API permission changes and retries before the posting pipeline stabilized.

Those are the kinds of operational problems clients shouldn't have to discover themselves on launch week.

By running the deployment on our own business first, we absorbed most of that instability before handing the system off.

Over the 10-day run:

• the agent published 15 posts,
• processed nearly 880k tokens locally,
• handled approvals through Telegram,
• and maintained a full audit trail of every action it took.

One thing we cared about heavily was keeping the system controlled.

The agent cannot publish directly without approval.
It cannot access unrestricted shell commands.
And the entire workflow runs on our own hardware instead of a third-party hosted model API.

That matters for businesses because customer conversations, listings, and business data stay inside the deployment instead of becoming training material somewhere else.

The interesting thing after operating this for a while is that the value isn't really "AI-generated posts."

The useful part is operational consistency.

The agent never forgets to draft.
Never forgets to schedule.
Never forgets to notify.
Never loses track of the queue.

It turns a repetitive business workflow into something supervised instead of manually operated.

The realtor originally asked us for "an AI agent for Facebook."

What we're really building is a managed operational system:
the agent, the runtime, the approvals, the monitoring, and the people maintaining it behind the scenes.

Running it on ourselves first made that difference very obvious.

A realtor approached us with a pretty straightforward request:

They wanted an AI agent that could help run their Facebook page.

The workflow they described was simple:

• they send listing details to the agent,
• the agent turns it into a Facebook post,
• the post gets scheduled automatically,
• and they receive updates through Telegram.

Before deploying it to them, we decided to run the same setup on our own business page first.

For the last 10 days, our own Facebook marketing has been handled through the exact workflow we're preparing for the realtor:

• we feed the system content briefs,
• the agent drafts posts in our page voice,
• scheduled jobs publish throughout the day,
• and every action routes back through Telegram for approval.

The reason we did this was simple:

If we wouldn't trust the system on our own page, we shouldn't ask a client to trust it on theirs.

What ended up being useful wasn't just proving the workflow worked, it was seeing what broke once the system started operating continuously.

A few examples:

At one point the audit system incorrectly marked a publishing session as incomplete even though the Facebook post had already gone live successfully.

Another issue came from Facebook itself, we spent part of the first few days dealing with Meta API permission changes and retries before the posting pipeline stabilized.

Those are the kinds of operational problems clients shouldn't have to discover themselves on launch week.

By running the deployment on our own business first, we absorbed most of that instability before handing the system off.

Over the 10-day run:

• the agent published 15 posts,
• processed nearly 880k tokens locally,
• handled approvals through Telegram,
• and maintained a full audit trail of every action it took.

One thing we cared about heavily was keeping the system controlled.

The agent cannot publish directly without approval.
It cannot access unrestricted shell commands.
And the entire workflow runs on our own hardware instead of a third-party hosted model API.

That matters for businesses because customer conversations, listings, and business data stay inside the deployment instead of becoming training material somewhere else.

The interesting thing after operating this for a while is that the value isn't really "AI-generated posts."

The useful part is operational consistency.

The agent never forgets to draft.
Never forgets to schedule.
Never forgets to notify.
Never loses track of the queue.

It turns a repetitive business workflow into something supervised instead of manually operated.

The realtor originally asked us for "an AI agent for Facebook."

What we're really building is a managed operational system:
the agent, the runtime, the approvals, the monitoring, and the people maintaining it behind the scenes.

Running it on ourselves first made that difference very obvious.

A real estate firm came to us wanting an AI agent that could run their Facebook page.

Not a scheduler.

An actual agent:

• ingest listing details,
• generate listing posts,
• schedule and publish them,
• and send updates back through Telegram.

Before deploying it to them, we ran the system on ourselves first.

For the last 10 days we've been operating an adjacent version against our own Facebook page using our runtime stack:

• local model (qwen3-coder-next)
• on-prem RTX 5090
• Telegram as operator interface
• Facebook Graph API skills
• hash-chained audit logging
• policy-gated tool execution
• human approval before outbound publishing

The deployment loop is simple:

Every day at 08:00, 10:00, and 14:00 the agent wakes up, pulls the next queued marketing brief, drafts a post in our page voice, sends it to Telegram for approval, and publishes it through Facebook once approved.

Every action leaves an audit entry behind it:

• cron firing
• LLM generation
• tool execution
• approval events
• outbound publishing

Each entry is chained, so the runtime can prove sequence integrity after the fact.

A few things we learned immediately:

1. Drift detection is harder than shipping content

Two sessions were marked accomplished=false even though:

• the Facebook post had already published,
• and the Telegram confirmation had already landed.

The work succeeded.
The session bookkeeping didn't.

Our drift heuristic was firing after successful execution and incorrectly classifying the run as incomplete.

This is exactly the kind of issue that never appears in demos but shows up quickly in production loops.

2. Policy-gated runtimes matter more than prompts

During the 10-day run the model attempted shell access six times.

All six were denied automatically at the runtime layer.

No prompt engineering.
No "please don't do that."
The runtime simply doesn't expose the capability.

That reinforced something we've been seeing repeatedly: agent reliability depends more on runtime constraints than model intelligence.

3. Facebook API churn is a real deployment cost

Early in the deployment we hit repeated graph_error retries while dealing with Meta permission and page-state changes.

By the end of the run the pipeline stabilized, but it reinforced why most "agent demos" stop before operational deployment.

Getting the model to generate text is easy, keeping integrations stable over time is the real work.

Runtime stats (10 days)

• Posts published: 15
• LLM calls: 121
• Tokens processed: 879,875
• Tool calls blocked by policy engine: 6
• Approval requests: 7
• Audit events: 121 hash-chained entries
• Successful first-pass sessions: 33 / 42

Inference cost on our side was effectively zero because the workload stayed local on our own hardware.

The realtor's deployment is structurally identical:
Telegram in, Facebook out, approval gate in the middle.

The only difference is the content queue.

The main takeaway from running this ourselves first is that production behavior is where the real engineering starts.

Most agent failures aren't generation failures, they're orchestration failures, state failures, policy failures, retry failures, or integration drift.

You only find those by operating the system continuously against real surfaces.

A real estate firm came to us wanting an AI agent that could run their Facebook page.

Not a scheduler.

An actual agent:

• ingest listing details,
• generate listing posts,
• schedule and publish them,
• and send updates back through Telegram.

Before deploying it to them, we ran the system on ourselves first.

For the last 10 days we've been operating an adjacent version against our own Facebook page using our runtime stack:

• local model (qwen3-coder-next)
• on-prem RTX 5090
• Telegram as operator interface
• Facebook Graph API skills
• hash-chained audit logging
• policy-gated tool execution
• human approval before outbound publishing

The deployment loop is simple:

Every day at 08:00, 10:00, and 14:00 the agent wakes up, pulls the next queued marketing brief, drafts a post in our page voice, sends it to Telegram for approval, and publishes it through Facebook once approved.

Every action leaves an audit entry behind it:

• cron firing
• LLM generation
• tool execution
• approval events
• outbound publishing

Each entry is chained, so the runtime can prove sequence integrity after the fact.

A few things we learned immediately:

1. Drift detection is harder than shipping content

Two sessions were marked accomplished=false even though:

• the Facebook post had already published,
• and the Telegram confirmation had already landed.

The work succeeded.
The session bookkeeping didn't.

Our drift heuristic was firing after successful execution and incorrectly classifying the run as incomplete.

This is exactly the kind of issue that never appears in demos but shows up quickly in production loops.

2. Policy-gated runtimes matter more than prompts

During the 10-day run the model attempted shell access six times.

All six were denied automatically at the runtime layer.

No prompt engineering.
No "please don't do that."
The runtime simply doesn't expose the capability.

That reinforced something we've been seeing repeatedly: agent reliability depends more on runtime constraints than model intelligence.

3. Facebook API churn is a real deployment cost

Early in the deployment we hit repeated graph_error retries while dealing with Meta permission and page-state changes.

By the end of the run the pipeline stabilized, but it reinforced why most "agent demos" stop before operational deployment.

Getting the model to generate text is easy, keeping integrations stable over time is the real work.

Runtime stats (10 days)

• Posts published: 15
• LLM calls: 121
• Tokens processed: 879,875
• Tool calls blocked by policy engine: 6
• Approval requests: 7
• Audit events: 121 hash-chained entries
• Successful first-pass sessions: 33 / 42

Inference cost on our side was effectively zero because the workload stayed local on our own hardware.

The realtor's deployment is structurally identical:
Telegram in, Facebook out, approval gate in the middle.

The only difference is the content queue.

The main takeaway from running this ourselves first is that production behavior is where the real engineering starts.

Most agent failures aren't generation failures, they're orchestration failures, state failures, policy failures, retry failures, or integration drift.

You only find those by operating the system continuously against real surfaces.

A real estate firm came to us wanting an AI agent that could run their Facebook page.

Not a scheduler.

An actual agent:

• ingest listing details,
• generate listing posts,
• schedule and publish them,
• and send updates back through Telegram.

Before deploying it to them, we ran the system on ourselves first.

For the last 10 days we've been operating an adjacent version against our own Facebook page using our runtime stack:

• local model (qwen3-coder-next)
• on-prem RTX 5090
• Telegram as operator interface
• Facebook Graph API skills
• hash-chained audit logging
• policy-gated tool execution
• human approval before outbound publishing

The deployment loop is simple:

Every day at 08:00, 10:00, and 14:00 the agent wakes up, pulls the next queued marketing brief, drafts a post in our page voice, sends it to Telegram for approval, and publishes it through Facebook once approved.

Every action leaves an audit entry behind it:

• cron firing
• LLM generation
• tool execution
• approval events
• outbound publishing

Each entry is chained, so the runtime can prove sequence integrity after the fact.

A few things we learned immediately:

1. Drift detection is harder than shipping content

Two sessions were marked accomplished=false even though:

• the Facebook post had already published,
• and the Telegram confirmation had already landed.

The work succeeded.
The session bookkeeping didn't.

Our drift heuristic was firing after successful execution and incorrectly classifying the run as incomplete.

This is exactly the kind of issue that never appears in demos but shows up quickly in production loops.

2. Policy-gated runtimes matter more than prompts

During the 10-day run the model attempted shell access six times.

All six were denied automatically at the runtime layer.

No prompt engineering.
No "please don't do that."
The runtime simply doesn't expose the capability.

That reinforced something we've been seeing repeatedly: agent reliability depends more on runtime constraints than model intelligence.

3. Facebook API churn is a real deployment cost

Early in the deployment we hit repeated graph_error retries while dealing with Meta permission and page-state changes.

By the end of the run the pipeline stabilized, but it reinforced why most "agent demos" stop before operational deployment.

Getting the model to generate text is easy, keeping integrations stable over time is the real work.

Runtime stats (10 days)

• Posts published: 15
• LLM calls: 121
• Tokens processed: 879,875
• Tool calls blocked by policy engine: 6
• Approval requests: 7
• Audit events: 121 hash-chained entries
• Successful first-pass sessions: 33 / 42

Inference cost on our side was effectively zero because the workload stayed local on our own hardware.

The realtor's deployment is structurally identical:
Telegram in, Facebook out, approval gate in the middle.

The only difference is the content queue.

The main takeaway from running this ourselves first is that production behavior is where the real engineering starts.

Most agent failures aren't generation failures, they're orchestration failures, state failures, policy failures, retry failures, or integration drift.

You only find those by operating the system continuously against real surfaces.