Wanted something lightweight for managing daily/weekly tasks across a small team without forcing everyone into a dashboard or spreadsheet — so I built Tasking: a Telegram bot backed by Postgres where you just talk to it in plain language and it handles the rest.
How it works:
You message the bot — “What are my tasks today?”, “Add a daily task for Alex at 9am” — and an AI Agent interprets the request and writes the PostgreSQL itself to read or update the database. No predefined commands, no menus.
A few things that make it useful for actual teams, not just one person:
Hierarchy-aware — the system knows who reports to whom. Employees can only see/edit their own tasks; managers automatically get elevated access to their direct reports’ tasks, enforced right in the AI agent’s logic.
Proactive, not just reactive — a second workflow handles morning previews, hourly due-task reminders, end-of-day summaries, and a daily rollup report to each manager so they’re not chasing status updates.
Structured + flexible — recurring daily/weekly tasks for routine work, plus one-off “extra tasks” and “uncharted” (no-deadline) tasks for things that don’t fit a fixed schedule.
Postgres-backed — built to actually hold up as the team and task history grow, not just a quick demo.
Stack: n8n, PostgreSQL, Telegram Bot, OpenAI (via AI Agent nodes)
Ongoing improvements
1- Weekly and monthly reports.
2- Departmentalization and project centered tasks.
Curious what you guys think and how can I optimize this more.
Also interested in how others are handling permission boundaries when giving an AI agent direct database write access
!
Solid build - the hierarchy-aware access enforced inside the agent’s logic rather than at the DB layer is the right approach for this use case.
On your question about permission boundaries: one practical pattern is to add a validation step before any SQL write where you pass the generated query through a second prompt (or a regex check) that blocks DROP, TRUNCATE, UPDATE without WHERE, or any query targeting a user_id other than the authenticated sender. Combined with Postgres row-level security tied to the user_id passed from the bot context, you get two independent layers - one at the AI level, one at the DB level. Worth adding before you scale to more teams.
Really appreciate the detailed breakdown, thank you.
The two-layer idea makes sense to me — I like that it doesn’t rely on the LLM “behaving” as the only safeguard. A regex/prompt pre-check on the generated SQL is cheap to add and catches the obvious stuff (DROP, TRUNCATE, unscoped UPDATE/DELETE), but you’re right that it shouldn’t be the only line of defense since a clever enough prompt injection could still slip something through.
RLS tied to user_id from the bot context is the part I’m most interested in — that’s a DB-level guarantee that holds even if the AI layer gets fooled, which is exactly the kind of independence you want between layers.