A new study found Grok's AI overwhelmingly recommends Republican candidates while OpenAI's GPT favors Democrats, with the two AI models disagreeing in more than 90% of nearly 500 election races.

My repo has 157 design specs and zero implementation plans… on purpose.

Between May and October 2026 I ran 415 issues and 320 pull requests on andrewconnell.com through one agentic engineering workflow: a GitHub issue written like a product requirements document (PRD), a brainstorm with Claude Code, a design spec I review, an implementation plan, an isolated git worktree, and a pull request. I keep the specs and throw the plans away.

Read the full article (24 minutes reading time): How I ran a 415-issue project with Claude Code and superpowers.

No cameras? No problem. Ditching the surveillance baggage makes Meta’s audio-only frames surprisingly easy to live with.

When you think of an agent, you think of the LLM - the back-and-forth with the model - but for it to be an agent, it has to do stuff. It has to have what is called a 'ReAct loop' in which the agent itself interacts with its environment, calls tools, and decides when its turn is done.

That seems very complicated - you have to create the conditions for the loop, you have to provide tools, you have to interpret the responses and route the messages with logic.

In addition to the ReAct loop, you need other things. You need chat history, the live working transcript, sessions, tool definitions, an environment in which to execute code, a way to compact the conversation, a place to store retrieved information. I wanted to see if I could build all of this in SQL. And I basically did. Its name is Tables.

What is Tables?

Tables is tables. Tables runs in a web app, but they don't have to. When you export from the web app, you get a single .sqlite file - a cartridge - and inside that file is the Python code that boots it: python3 your-agent.sqlite3 "What tables do I have?" and they talk back to you.

Tables is built on SQLite. SQLite does need a small amount of external piping to come to life - in my case a bit of JavaScript for the web app, or a little Python for the CLI. To be honest about what "almost" means: what lives outside the file is one HTTPS call out to a model, the ferry that carries it, the thing that draws the results on screen, and your API keys. The agent's entire state and control flow are the file. Everything else is the HTTPS transportation layer.

The loop is just a trigger.

The core loop is a trigger. When a new row is written to the `messages` table, the trigger fires and the cascade starts: it hands the active context to the model, writes the model's answer back into `messages` as a new row, and that insert fires the same trigger again.

If the answer contained a tool call, a second trigger runs the tool and its result lands in `messages` too, which continues the cascade. It repeats until the model stops asking for tools. That's the whole loop, and it needs one flag to exist at all: SQLite doesn't fire triggers from inside triggers by default, so the file sets `PRAGMA recursive_triggers = ON` and calls itself to life.

The model's main tool is `execute_sql` - it thinks and acts inside a SQLite database, which is its whole environment. I did build out the rest of the tool set because I wanted something I could actually use: `search_web` and `fetch_url` because those are table stakes, `materialize` to turn raw JSON from a tool result into a real table with `json_each()` so the data doesn't have to be retyped through the model, and `search_documents` / `ingest_document` backed by an FTS5 table for recall.

Messages are a table. Sessions are a table. The list of tools - a table. Approval rules? Table. The active context is a view that handles compaction. And as mentioned before, the loop is a trigger.

Unexpected Outcomes

There are some cool things that fall out of this when compared to other agent harnesses. Tables is literally one file. You can take your .sqlite3, send it to another computer, open tables.nicholaslisac.com, load the cartridge, and your agent is good to go - same conversation, same data, same identity - or run the Python that's sitting in the file and never open a browser. The API key never travels in the file; it gets paired once per machine for security.

The chat history is native and easily explorable. Everything the agent has ever done or seen is in the SQLite database it operates from, and nothing is more than a SQL query away. Every write is journaled with who made it - the agent, you at the keyboard, or the interface on your behalf - so a turn can be undone without undoing your own work.

Everything the agent learns ends up in the same place as everything you give it. Drop a CSV on the window, and it becomes a typed table; have it fetch a page and materialize the results, and that becomes a table too. After that they all swim the same way, because for the agent there is no difference between its own history and your data - it's all just rows and columns.

Tables is naturally sandboxed to their database file, with the exception of their web capabilities. The agent can't touch your filesystem, can't install anything, can't notify you. It can't even break its own harness - the internal tables are protected from DDL and DML, on the agent's path and yours.

You also get a scratchpad so Tables acts as your own SQL workbench: !SQL runs your query and shares the result with the agent, !!SQL runs it privately and the agent never sees it. And if you pin a query you like, it becomes an artifact.

Is this the future of Agent harnesses?!

Absolutely not. I wondered if I could build an AI agent loop with SQL as the engine and set out to see if it worked. I got a little carried away and made an entire web app to prove a point. It's part research project, part portfolio piece. And I like it.

Tables is not a coding agent. It doesn't have access to other files on your computer. It can't do most things people want out of their AI in 2026. Tables is just tables. But those tables can talk back to you, do real work in a database, do analysis and gather information from around the internet, and prove that SQL is (almost) as powerful as languages like Python or TypeScript.

The code is open - you can see it on GitHub, and you can check out the explainer here or go right to the app here: tables.nicholaslisac.com. You can use Tables, but you will need to BYOK, whether that is local or cloud.

No guarantee of performance or success - but it will probably be fun to talk to Tables.

As organizations embrace AI, cloud modernization, and increasingly complex application architectures, the database estate continues to grow. What was once a handful of databases can quickly become hundreds or thousands of resources spread across subscriptions, regions, clouds, and database platforms. 

Security teams and database administrators face a common challenge: understanding the security posture of this growing estate and knowing where to focus attention first. While security controls exist across individual database services, assessing security posture at an estate level often requires navigating multiple portals, manually collecting findings, and piecing together information from different tools. 

Database Hub in Microsoft Fabric, now in public preview, gives database teams a unified place to discover their database estate and review security posture across supported database platforms. This estate-wide experience helps teams identify potential security gaps, understand where attention may be needed, and determine the right next step to improve overall security posture for databases. 

Security challenges at database estate scale 

Most organizations are no longer managing a single database platform. A typical enterprise environment may include: Azure SQL Database, Azure Database for PostgreSQL, Azure Cosmos DB, SQL Server instances running on-premises or through Azure Arc, SQL databases running inside Microsoft Fabric and additional database platforms. 

As environments expand, common security questions become increasingly difficult to answer: 

• Which databases require attention?
• Where are security best practices not being followed?
• Which issues affect the largest portion of the estate?
• What action should be taken first? 

Customers need a simpler way to assess security posture across the entire estate rather than investigating databases individually. 

Database Hub was designed to help answer those questions. 

Security posture at a glance 

Database Hub provides a centralized view of database inventory, health, performance, optimization opportunities, and security findings across supported platforms. 

For security scenarios, the goal is simple: Help customers quickly understand the current posture of their database estate and identify the issues that matter most. 

Database Hub aggregates security findings across available resources and presents them in an estate-wide view, allowing teams to immediately see areas that require attention. Instead of manually reviewing databases one at a time, administrators can start with a single consolidated view and understand where security gaps exist across their environment. 

The current public preview introduces an initial set of security checks across supported database platforms. Depending on the database type, these checks cover areas such as authentication, data protection, auditing, and network security. For details about the checks currently available for database resources, refer to the Learn documentation.  

As we continue to work with customers throughout the preview and beyond, we will use feedback to refine the security experience, expand coverage across database platforms, and introduce additional capabilities. 

These signals aren't intended to replace the deeper security capabilities available within each database platform. Instead, Database Hub provides an estate-level starting point for identifying potential gaps and deciding where to investigate further. Database Hub complements existing security products and services by providing a unified view of broadly applicable security practices across the database estate. Customers can use these experiences together for a more complete understanding of database security posture. 

Prioritize what matters most 

Not all security findings have the same impact. Some controls affect a small number of databases. Others may represent risks across large portions of the estate. 

Database Hub helps customers focus on their investigation by distinguishing security issues that may require immediate attention from longer-term suggestions, and by showing how many resources are affected. This estate-wide context helps teams understand the potential scope of a finding and decide where to investigate first. 

Rather than asking: "Which database should I investigate next?" 

Teams can answer: "Which security issue should I address first?" 

Move from discovery to action 

Visibility alone is not enough. Once a finding is identified, the next step is to understand why it matters and what action should be taken. 

Database Hub provides additional context for findings and helps guide customers toward remediation. Teams can review affected resources, understand the recommendation, and, where supported, refer to relevant documentation and continue to the appropriate management experience to take corrective action. 

What’s next for security in Database Hub 

The security signals described above are available as part of the current public preview. Looking ahead, we plan to build on this foundation with additional capabilities that help teams continuously understand, prioritize, and improve security posture across their database estate. We are exploring several areas of investment, including: 

• Broader security coverage: We plan to add security signals across more supported database types and security areas, providing a more complete picture of your database security posture. 

• A dedicated Security page in Database Hub: We plan to create a focused experience that brings security posture, prioritized findings, and affected resources together. The goal is to help security administrators understand overall posture at a glance, see what parts of the estate need attention, and take the right action to improve it. 

• Agentic security analysis: We are exploring agentic capabilities that go beyond configuration-based checks to analyze more complex security scenarios and surface insights, for example, identifying users or applications that may have more privileges than they need and recommend opportunities to move toward least-privilege access. 

These capabilities represent our forward-looking direction and are not part of the current preview. Customer feedback will help us refine this vision and prioritize the capabilities that provide the greatest value. 

Try security experiences in Database Hub today 

Whether you're responsible for a handful of databases or a global database estate spanning multiple platforms, Database Hub provides a simpler way to understand security posture, prioritize action, and move towards a more secure database environment. If you're using Database Hub today, you can already explore the available security experiences and security findings across supported database platforms. 

As you explore Database Hub, we’d love to hear which security signals, insights, and agentic experiences would be most valuable for managing your database estate. Please share your feedback directly within Database Hub by using the "Feedback" option. Your feedback will help us prioritize the capabilities and experiences we build next and align the Database Hub security roadmap with how you manage security in real-world database estates. 

We're excited to continue learning from customers and shaping the next generation of database security experiences together. 

Learn more 

• Explore Database Hub in Microsoft Fabric 

• Review Database Hub documentation on Microsoft Learn 

GitHub can now bring repository updates into a channel, group chat, or private chat. When an update needs action, reply to the notification and @mention GitHub with the task you want GitHub Copilot to carry out.

GitHub Copilot uses the issue or pull request linked in the notification and the conversation in the thread to understand the task. It can reproduce a bug, run tests, implement a fix, and prepare a pull request for review.

Turn an issue notification into a pull request

For a bug report, the workflow starts in the notification thread:

1. A GitHub Issue notification arrives in a Teams channel with a link to the reported bug.
2. You @mention GitHub to investigate the issue and prepare a proposed fix in a pull request.
3. The team reviews the pull request, iterates with GitHub Copilot, tests the proposed changes, and decides whether to merge.

Starting from the linked issue and thread lets your team delegate the work to GitHub Copilot without rebuilding the request from scratch. The same workflow can be used to implement a feature, expand test coverage, update documentation, and more. Product and engineering teams at Microsoft are already leveraging the GitHub app in Teams to build products today.

Get started

Explore the new GitHub app in Microsoft Teams (previously called GitHub Notifications). If you already have GitHub Notifications installed, update the app to the latest version. The legacy GitHub app will be renamed “GitHub (deprecated)” and retired on November 16. Learn more at teams.github.com!

Turn the updates your team follows into code your team can review.