Is it possible to create a ciphersuite for TLS 1.3 using only the Keccak-sponge/duplex? Now that Keccak has been chosen as SHA-3 we see that there have been defined quite a few related modes, including authenticated cipher modes, the KMAC message authentication mode, XOF's and whatnot. However, it is unclear to me how much this fills all the gaps for symmetric cryptography. Could we for instance define and implement a TLS 1.3 cipher suite to use just constructions solely based on the Keccak-sponge/duplex as primitive? Simple bit operations and loops are of course permitted to tie everything together.
So besides KMAC we'd likely need to have a well defined and preferably standardized KDF and a secure random number generator (preferably one that can be reseeded). Additional points go to the answer that also manages to indicate a method of authentication (hash-based signatures?) and, possibly more tricky, a key agreement scheme to replace (EC)DH.
First for the scope of such a ciphersuite, to quote RFC 8446 Section B.4:

A symmetric cipher suite defines the pair of the AEAD algorithm and hash algorithm to be used with HKDF.

Now to the first question:

Could we for instance define and implement a TLS 1.3 cipher suite to use just constructions solely based on the Keccak-sponge as primitive?

With the above definition of what a cipher suite is, this seems easy enough, we just pair either of Keyak or Ketje with SHA-3 or KangarooTwelve. One of the first two mentioned AEAD schemes would be mostly used for bulk encryption and one of the latter two hash functions via HKDF for key derivation. I'm not sure how much customization TLS 1.3 allows but it might also be possible for an RFC to define Keccak based ciphersuites to use a different KDF than HKDF, though this would most likely lower acceptance.

Additional points go to the answer that also manages to indicate a method of authentication (hash-based signatures?)

Indeed it would be possible to use either of the hash-based NIST PQC Round 3 Alternative candidates for this. In fact Picnic is already based on Keccak (and LowMC to build a MPC-based signature scheme). Additionally SPHINCS+ is also specified for SHAKE-256 for the NIST PQC.

and, possibly more tricky, a key agreement scheme to replace (EC)DH.

Constructing key agreement (or public-key encryption) from hash functions is very unlikely even for theoretical constructions (assuming collision-resistance). It is very much impossible to do so generically only assuming the existence of black-box One-Way-Functions as shown by Rudich and Impaglazzio in STOCS 1989's &quot;Limits on Provable Consequences of One-way Permutations&quot; (PDF).