u/SeNorMat

I’m building a client workflow dashboard and need architecture advice.

I’m trying to keep the dashboard/database as the source of truth and use the bot as a command layer, but I’m not sure if that’s the right pattern.

Each client would have workspaces, agents/workflows, run logs, outputs, analytics, and approvals.

I want a conversational control layer where I can type things like:

* “Run monthly report for Client A”

* “Show failed workflows”

* “Add SEO workflow to Client B”

* “Create a GitHub PR for this agent config”

* “Summarize this week’s outputs”

I’m debating where the bot should live:

* Slack bot

* Telegram bot

* chat panel inside the dashboard

* combination of the above

Stack I’m considering:

* Vercel dashboard

* Railway API/orchestrator

* Postgres

* GitHub for configs/code changes

* LLM API

* background job queue

Main question:

What’s the cleanest way to connect a conversational bot to deployed workflows?

Should the bot call APIs directly, create queued jobs, trigger GitHub workflows, or only create approval requests that the dashboard executes?

I’m especially interested in permissioning, audit logs, human approval steps, and avoiding accidental production changes.

I’m building a client workflow dashboard and need architecture advice.

I’m trying to keep the dashboard/database as the source of truth and use the bot as a command layer, but I’m not sure if that’s the right pattern.

Each client would have workspaces, agents/workflows, run logs, outputs, analytics, and approvals.

I want a conversational control layer where I can type things like:

* “Run monthly report for Client A”

* “Show failed workflows”

* “Add SEO workflow to Client B”

* “Create a GitHub PR for this agent config”

* “Summarize this week’s outputs”

I’m debating where the bot should live:

* Slack bot

* Telegram bot

* chat panel inside the dashboard

* combination of the above

Stack I’m considering:

* Vercel dashboard

* Railway API/orchestrator

* Postgres

* GitHub for configs/code changes

* LLM API

* background job queue

Main question:

What’s the cleanest way to connect a conversational bot to deployed workflows?

Should the bot call APIs directly, create queued jobs, trigger GitHub workflows, or only create approval requests that the dashboard executes?

I’m especially interested in permissioning, audit logs, human approval steps, and avoiding accidental production changes.

I’m building a client workflow dashboard and need architecture advice.

I’m trying to keep the dashboard/database as the source of truth and use the bot as a command layer, but I’m not sure if that’s the right pattern.

Each client would have workspaces, agents/workflows, run logs, outputs, analytics, and approvals.

I want a conversational control layer where I can type things like:

* “Run monthly report for Client A”

* “Show failed workflows”

* “Add SEO workflow to Client B”

* “Create a GitHub PR for this agent config”

* “Summarize this week’s outputs”

I’m debating where the bot should live:

* Slack bot

* Telegram bot

* chat panel inside the dashboard

* combination of the above

Stack I’m considering:

* Vercel dashboard

* Railway API/orchestrator

* Postgres

* GitHub for configs/code changes

* LLM API

* background job queue

Main question:

What’s the cleanest way to connect a conversational bot to deployed workflows?

Should the bot call APIs directly, create queued jobs, trigger GitHub workflows, or only create approval requests that the dashboard executes?

I’m especially interested in permissioning, audit logs, human approval steps, and avoiding accidental production changes.

I'm building an AI agent platform (think automated outreach + marketing agents for small businesses and job seekers). I need to pick an infrastructure approach for social and email automation and want your thoughts before I commit. What the agents actually need to do:

Cold outreach agent (the main one) — send LinkedIn connection requests with a personalized note, send DMs to accepted connections, read the inbox and detect replies. Same flow for Instagram DMs (trigger-based, not cold). Standard email sequences too.
Content/posting (secondary, for clients) — post to LinkedIn on a schedule. Probably other platforms too eventually.
The three options I'm weighing:

Option A — Build my own LinkedIn layer
Use LinkedIn's internal Voyager API (li_at session cookie + direct HTTP calls to their private endpoints). Open-source libraries like linkedin-api on PyPI already do 80% of this. I'd wrap it in a small FastAPI service and expose it as an MCP tool for the agent to call.

Cost: free. Build time: ~1 day. Risk: LinkedIn just banned HeyReach in March 2026 for doing exactly this (API calls without a browser fingerprint). Raw API calls are detectable within 48 hours now per their updated session fingerprinting.

Option B — Third-party API (Unipile or LinkedAPI.io)
Both wrap the same Voyager API but add session management, proxy rotation, and reliability. LinkedAPI.io specifically runs a real cloud browser per account (mimics human behavior more convincingly) and ships an MCP server I can plug straight into the agent. Unipile is more mature.
Cost: ~$49-55/month per LinkedIn account. No build time.

Unipile also covers Instagram DMs through the same API. For email I'd integrate separately (probably Resend or similar).

Option C — Keep browser control for LinkedIn
Currently the agent drives a real Chrome session via an MCP extension (Claude in Chrome). LinkedIn sees a real human browser — lowest detection risk. Works today. Downside: tied to a local machine, can't cloud-host the agent, fragile when LinkedIn's UI changes.

What I'm trying to figure out:

Is it worth building the Voyager API layer myself given the ban risk, or does the ban risk make Option A a non-starter?
For the full use case (LinkedIn outreach + Instagram DMs + email + LinkedIn posting), does it make more sense to unify everything under one provider like Unipile, or stitch together best-in-class per channel?
If you were building this, what would you do?
Context: current volume is one LinkedIn account at 20 sends/day with personalized notes. Will eventually scale to multiple accounts across multiple clients.

I'm building an AI agent platform (think automated outreach + marketing agents for small businesses and job seekers). I need to pick an infrastructure approach for social and email automation and want your thoughts before I commit. What the agents actually need to do:

Cold outreach agent (the main one) — send LinkedIn connection requests with a personalized note, send DMs to accepted connections, read the inbox and detect replies. Same flow for Instagram DMs (trigger-based, not cold). Standard email sequences too.
Content/posting (secondary, for clients) — post to LinkedIn on a schedule. Probably other platforms too eventually.
The three options I'm weighing:

Option A — Build my own LinkedIn layer
Use LinkedIn's internal Voyager API (li_at session cookie + direct HTTP calls to their private endpoints). Open-source libraries like linkedin-api on PyPI already do 80% of this. I'd wrap it in a small FastAPI service and expose it as an MCP tool for the agent to call.

Cost: free. Build time: ~1 day. Risk: LinkedIn just banned HeyReach in March 2026 for doing exactly this (API calls without a browser fingerprint). Raw API calls are detectable within 48 hours now per their updated session fingerprinting.

Option B — Third-party API (Unipile or LinkedAPI.io)
Both wrap the same Voyager API but add session management, proxy rotation, and reliability. LinkedAPI.io specifically runs a real cloud browser per account (mimics human behavior more convincingly) and ships an MCP server I can plug straight into the agent. Unipile is more mature.
Cost: ~$49-55/month per LinkedIn account. No build time.

Unipile also covers Instagram DMs through the same API. For email I'd integrate separately (probably Resend or similar).

Option C — Keep browser control for LinkedIn
Currently the agent drives a real Chrome session via an MCP extension (Claude in Chrome). LinkedIn sees a real human browser — lowest detection risk. Works today. Downside: tied to a local machine, can't cloud-host the agent, fragile when LinkedIn's UI changes.

What I'm trying to figure out:

Is it worth building the Voyager API layer myself given the ban risk, or does the ban risk make Option A a non-starter?
For the full use case (LinkedIn outreach + Instagram DMs + email + LinkedIn posting), does it make more sense to unify everything under one provider like Unipile, or stitch together best-in-class per channel?
If you were building this, what would you do?
Context: current volume is one LinkedIn account at 20 sends/day with personalized notes. Will eventually scale to multiple accounts across multiple clients.