What is Tim and how does it work with Microsoft 365?

Tim is an AI Chief of Staff that integrates natively with Microsoft 365 and Slack. It connects to Outlook, Teams, SharePoint, OneDrive, Word, Excel, PowerPoint, Planner, and To Do via the Microsoft Graph API. Tim can read and triage emails, manage your calendar, search files, handle Teams messages, create tasks, and automate multi-step workflows — all while asking for confirmation before taking sensitive actions.

How is Tim different from Microsoft Copilot?

Microsoft Copilot suggests actions and generates content. Tim actually executes tasks autonomously — it sends emails, creates calendar events, moves files, and manages tasks on your behalf. Tim uses a human-in-the-loop confirmation system for sensitive actions, so you stay in control. Tim also works across all M365 apps simultaneously, not just within one app at a time.

Is Tim secure and does it comply with enterprise standards?

Tim uses OAuth 2.0 authentication with Microsoft Azure AD, never stores email content or message bodies, and operates within your existing Microsoft 365 security boundaries. Workspace admins have full governance controls including tool-level permissions, audit logs, and the ability to restrict which actions Tim can take. Admin dashboards show aggregate usage without exposing individual message content.

Tim offers a free Starter tier with $100 in credits, a Pro plan at $39/month for individual professionals, a Team plan at $29/user/month for teams of 6-100 users (with a 20% discount on annual billing), and custom Enterprise pricing with dedicated support and SLAs.

What tasks can Tim automate in Microsoft 365 and Slack?

Tim can automate email triage and replies, calendar scheduling and meeting prep, file search and document summarisation, task creation and management, Teams message monitoring and responses, multi-step workflows combining actions across apps, and scheduled recurring tasks. Tim supports 37 tools across 38 Microsoft Graph API operations.

arrow_back Back to Intelligence Hub

ProductMay 9, 2026· 4 min read

Tim Publishes Its Own Blog: How We're Eating Our Own Dogfood

We just shipped the markdown loader and GitHub-repo destination. Every article from here on — including this one — flows through the same Tim Publishing pipeline we're building for customers.

This is the first article published through Tim's new content pipeline. The infrastructure underneath it is the same infrastructure that will power customers' own blogs once we hit GA.

What just shipped

Three things landed today that together close the loop on automated publishing:

Multi-tenant article generator (backend/scripts/generate_article.py) that takes a workspace ID, keyword, and optional cluster context and produces a quality-gated article via Gemini. Brand voice, audience persona, and topic context all come from per-workspace settings — Tim's own articles use Tim's voice, customer articles use theirs.
GitHub-repo destination (backend/app/integrations/publish_destinations/github_repo.py) that commits the markdown file with YAML frontmatter, opens a PR on Tim's repo, and returns the PR URL as the preview. Azure Static Web Apps' built-in PR-preview feature gives every PR a deploy URL automatically — no extra wiring needed.
Markdown loader (webapp/src/lib/blog-data.ts) that uses Vite's import.meta.glob to discover every .md file under webapp/src/content/blog/, parses the frontmatter with js-yaml, and renders the body with marked plus DOMPurify for HTML sanitization. The existing BlogArticle.tsx component renders the result with no visual change to what readers see — same italic display headline, same drop cap, same surface container, same tag chip.

Why markdown, why git, why no CMS

Three reasons the storage choice matters:

Zero infrastructure cost. No headless CMS subscription. No database table. No admin UI to maintain. Git is the source of truth, and the existing GitHub + Azure SWA deploy pipeline picks up new articles on every merge to main.

Version control built in. Every article edit is a commit. Every published version has a SHA. Rollback is git revert. This matters more at 10,000 articles than at 10.

LLM-first publishing fits the model. When the "writer" is an LLM that opens PRs against a repo, the workflow already maps to git: branch, commit, PR, review, merge. A CMS would just be an unnecessary layer between Tim and the article. For workspaces with human writers who need a web admin, the same markdown source can be edited through TinaCMS or Decap CMS — but that's an opt-in layer, not a default cost.

What's next

The pipeline works end-to-end for Tim's own blog, but customer-facing publishing needs three more pieces:

Confirmation Loop integration so customers can approve drafts via Slack/Teams reply instead of merging GitHub PRs manually.
WordPress destination — the same PublishDestination interface, talking to the WordPress REST API via Pipedream-issued OAuth tokens. Adds the ~43% of the web that runs on WordPress.
LinkedIn syndication — the first SyndicationChannel. Once an article publishes, Tim fans out an excerpt + canonical link to the workspace's LinkedIn presence.

Each of those is its own focused PR. The scaffolding makes them additive — no rewrites required.

How to verify this article rendered correctly

If you're reading this on gettim.co/blog/sample-tim-publishes-its-own-blog, the markdown loader works. The cover area, headline, tag, and date came from the YAML frontmatter at the top of this file. The body — including this paragraph — came from the markdown below the frontmatter, parsed by marked and sanitized by DOMPurify. The five FAQ pairs above will render as a structured FAQ section once the BlogArticle component picks them up from the frontmatter.

This is the foundation. Every Tim-published article from here forward — for Tim, for customers — flows through this exact pipeline.

Frequently asked

Does this mean Tim wrote this article itself?expand_more

This particular article was hand-written to verify the publishing pipeline. From the next article forward, Tim drafts the body via Gemini, opens a PR, and a human editor reviews and approves before merge.

Where does the markdown live?expand_more

Every article is a markdown file under webapp/src/content/blog/ in the Tim repo. Vite's import.meta.glob discovers them at build time and the BlogArticle component renders them with frontmatter-driven metadata.

How does Tim know what to write about?expand_more

Tim mines connected tools — Salesforce won/lost deals, Google Search Console impressions, recurring Slack questions, support inbox topics — to suggest article topics. Editors approve or override before generation.

What happens if the LLM generates low-quality content?expand_more

Every article passes through a quality gate: minimum 1,200 words for supporting articles (3,000 for pillar pages), at least 5 FAQ pairs, a 40–60 word definitive lead answer for featured-snippet capture, and at least one specific data point or named example. Articles that fail the gate are rejected before the PR opens.

When will customers be able to use this?expand_more

Tim's own blog is the dogfood validation phase. Customer-facing access goes live after the WordPress destination, LinkedIn syndication, and Confirmation Loop integration land — tracked in our Phase 0 plan.

person

Tim Engineering

Drafted by Tim · Reviewed by editor